begriffs open source - ai-pg/blob - full-docs/txt/logical-replication-failover.txt

   1
   2 29.3. Logical Replication Failover #
   3
   4    To allow subscriber nodes to continue replicating data from the
   5    publisher node even when the publisher node goes down, there must be a
   6    physical standby corresponding to the publisher node. The logical slots
   7    on the primary server corresponding to the subscriptions can be
   8    synchronized to the standby server by specifying failover = true when
   9    creating subscriptions. See Section 47.2.3 for details. Enabling the
  10    failover parameter ensures a seamless transition of those subscriptions
  11    after the standby is promoted. They can continue subscribing to
  12    publications on the new primary server.
  13
  14    Because the slot synchronization logic copies asynchronously, it is
  15    necessary to confirm that replication slots have been synced to the
  16    standby server before the failover happens. To ensure a successful
  17    failover, the standby server must be ahead of the subscriber. This can
  18    be achieved by configuring synchronized_standby_slots.
  19
  20    To confirm that the standby server is indeed ready for failover for a
  21    given subscriber, follow these steps to verify that all the logical
  22    replication slots required by that subscriber have been synchronized to
  23    the standby server:
  24     1. On the subscriber node, use the following SQL to identify which
  25        replication slots should be synced to the standby that we plan to
  26        promote. This query will return the relevant replication slots
  27        associated with the failover-enabled subscriptions.
  28 /* sub # */ SELECT
  29                array_agg(quote_literal(s.subslotname)) AS slots
  30            FROM  pg_subscription s
  31            WHERE s.subfailover AND
  32                  s.subslotname IS NOT NULL;
  33  slots
  34 -------
  35  {'sub1','sub2','sub3'}
  36 (1 row)
  37
  38     2. On the subscriber node, use the following SQL to identify which
  39        table synchronization slots should be synced to the standby that we
  40        plan to promote. This query needs to be run on each database that
  41        includes the failover-enabled subscription(s). Note that the table
  42        sync slot should be synced to the standby server only if the table
  43        copy is finished (See Section 52.55). We don't need to ensure that
  44        the table sync slots are synced in other scenarios as they will
  45        either be dropped or re-created on the new primary server in those
  46        cases.
  47 /* sub # */ SELECT
  48                array_agg(quote_literal(slot_name)) AS slots
  49            FROM
  50            (
  51                SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_
  52 identifier) AS slot_name
  53                FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscript
  54 ion s
  55                WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover
  56            );
  57  slots
  58 -------
  59  {'pg_16394_sync_16385_7394666715149055164'}
  60 (1 row)
  61
  62     3. Check that the logical replication slots identified above exist on
  63        the standby server and are ready for failover.
  64 /* standby # */ SELECT slot_name, (synced AND NOT temporary AND invalidation_rea
  65 son IS NULL) AS failover_ready
  66                FROM pg_replication_slots
  67                WHERE slot_name IN
  68                    ('sub1','sub2','sub3', 'pg_16394_sync_16385_73946667151490551
  69 64');
  70   slot_name                                 | failover_ready
  71 --------------------------------------------+----------------
  72   sub1                                      | t
  73   sub2                                      | t
  74   sub3                                      | t
  75   pg_16394_sync_16385_7394666715149055164   | t
  76 (4 rows)
  77
  78    If all the slots are present on the standby server and the result
  79    (failover_ready) of the above SQL query is true, then existing
  80    subscriptions can continue subscribing to publications on the new
  81    primary server.
  82
  83    The first two steps in the above procedure are meant for a PostgreSQL
  84    subscriber. It is recommended to run these steps on each subscriber
  85    node, that will be served by the designated standby after failover, to
  86    obtain the complete list of replication slots. This list can then be
  87    verified in Step 3 to ensure failover readiness. Non-PostgreSQL
  88    subscribers, on the other hand, may use their own methods to identify
  89    the replication slots used by their respective subscriptions.
  90
  91    In some cases, such as during a planned failover, it is necessary to
  92    confirm that all subscribers, whether PostgreSQL or non-PostgreSQL,
  93    will be able to continue replication after failover to a given standby
  94    server. In such cases, use the following SQL, instead of performing the
  95    first two steps above, to identify which replication slots on the
  96    primary need to be synced to the standby that is intended for
  97    promotion. This query returns the relevant replication slots associated
  98    with all the failover-enabled subscriptions.
  99
 100 /* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots
 101                FROM pg_replication_slots r
 102                WHERE r.failover AND NOT r.temporary;
 103  slots
 104 -------
 105  {'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'}
 106 (1 row)