@@ -709,8 +709,8 @@ HINT: To initiate replication, you must manually create the replication slot, e
709
709
</para>
710
710
711
711
<para>
712
- To confirm that the standby server is indeed ready for failover, follow these
713
- steps to verify that all necessary logical replication slots have been
712
+ To confirm that the standby server is indeed ready for failover for a given subscriber , follow these
713
+ steps to verify that all the logical replication slots required by that subscriber have been
714
714
synchronized to the standby server:
715
715
</para>
716
716
@@ -764,7 +764,7 @@ HINT: To initiate replication, you must manually create the replication slot, e
764
764
Check that the logical replication slots identified above exist on
765
765
the standby server and are ready for failover.
766
766
<programlisting>
767
- /* standby # */ SELECT slot_name, (synced AND NOT temporary AND NOT conflicting ) AS failover_ready
767
+ /* standby # */ SELECT slot_name, (synced AND NOT temporary AND invalidation_reason IS NULL ) AS failover_ready
768
768
FROM pg_replication_slots
769
769
WHERE slot_name IN
770
770
('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164');
@@ -782,10 +782,42 @@ HINT: To initiate replication, you must manually create the replication slot, e
782
782
<para>
783
783
If all the slots are present on the standby server and the result
784
784
(<literal>failover_ready</literal>) of the above SQL query is true, then
785
- existing subscriptions can continue subscribing to publications now on the
786
- new primary server.
785
+ existing subscriptions can continue subscribing to publications on the new
786
+ primary server.
787
+ </para>
788
+
789
+ <para>
790
+ The first two steps in the above procedure are meant for a
791
+ <productname>PostgreSQL</productname> subscriber. It is recommended to run
792
+ these steps on each subscriber node, that will be served by the designated
793
+ standby after failover, to obtain the complete list of replication
794
+ slots. This list can then be verified in Step 3 to ensure failover readiness.
795
+ Non-<productname>PostgreSQL</productname> subscribers, on the other hand, may
796
+ use their own methods to identify the replication slots used by their
797
+ respective subscriptions.
798
+ </para>
799
+
800
+ <para>
801
+ In some cases, such as during a planned failover, it is necessary to confirm
802
+ that all subscribers, whether <productname>PostgreSQL</productname> or
803
+ non-<productname>PostgreSQL</productname>, will be able to continue
804
+ replication after failover to a given standby server. In such cases, use the
805
+ following SQL, instead of performing the first two steps above, to identify
806
+ which replication slots on the primary need to be synced to the standby that
807
+ is intended for promotion. This query returns the relevant replication slots
808
+ associated with all the failover-enabled subscriptions.
787
809
</para>
788
810
811
+ <para>
812
+ <programlisting>
813
+ /* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots
814
+ FROM pg_replication_slots r
815
+ WHERE r.failover AND NOT r.temporary;
816
+ slots
817
+ -------
818
+ {'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'}
819
+ (1 row)
820
+ </programlisting></para>
789
821
</sect1>
790
822
791
823
<sect1 id="logical-replication-row-filter">
0 commit comments