database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-18 17:42:25 +03:00
Code Activity

Doc: Improve logical replication failover documentation.

Browse Source 
Clarified that the failover steps apply to a specific PostgreSQL subscriber
and added guidance for verifying replication slot synchronization during
planned failover. Additionally, corrected the standby query to avoid false
positives by checking invalidation_reason IS NULL instead of conflicting.

Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Author: Shveta Malik <shveta.malik@gmail.com>
Backpatch-through: 17, where it was introduced
Discussion: https://www.postgresql.org/message-id/CAExHW5uiZ-fF159=jwBwPMbjZeZDtmcTbN+hd4mrURLCg2uzJg@mail.gmail.com
This commit is contained in:
Amit Kapila
2025-07-09 09:44:27 +05:30
parent fef6da9e9c
commit 24f608625f
1 changed files with 37 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
doc/src/sgml/logical-replication.sgml
View File

@ -709,8 +709,8 @@ HINT: To initiate replication, you must manually create the replication slot, e
</para>
<para>
To confirm that the standby server is indeed ready for failover, follow these
steps to verify that all necessary logical replication slots have been
To confirm that the standby server is indeed ready for failover for a given subscriber, follow these
steps to verify that all the logical replication slots required by that subscriber have been
synchronized to the standby server:
</para>
@ -764,7 +764,7 @@ HINT: To initiate replication, you must manually create the replication slot, e
Check that the logical replication slots identified above exist on
the standby server and are ready for failover.
<programlisting>
/* standby # */ SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS failover_ready
/* standby # */ SELECT slot_name, (synced AND NOT temporary AND invalidation_reason IS NULL) AS failover_ready
FROM pg_replication_slots
WHERE slot_name IN
('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164');
@ -782,10 +782,42 @@ HINT: To initiate replication, you must manually create the replication slot, e
<para>
If all the slots are present on the standby server and the result
(<literal>failover_ready</literal>) of the above SQL query is true, then
existing subscriptions can continue subscribing to publications now on the
new primary server.
existing subscriptions can continue subscribing to publications on the new
primary server.
</para>
<para>
The first two steps in the above procedure are meant for a
<productname>PostgreSQL</productname> subscriber. It is recommended to run
these steps on each subscriber node, that will be served by the designated
standby after failover, to obtain the complete list of replication
slots. This list can then be verified in Step 3 to ensure failover readiness.
Non-<productname>PostgreSQL</productname> subscribers, on the other hand, may
use their own methods to identify the replication slots used by their
respective subscriptions.
</para>
<para>
In some cases, such as during a planned failover, it is necessary to confirm
that all subscribers, whether <productname>PostgreSQL</productname> or
non-<productname>PostgreSQL</productname>, will be able to continue
replication after failover to a given standby server. In such cases, use the
following SQL, instead of performing the first two steps above, to identify
which replication slots on the primary need to be synced to the standby that
is intended for promotion. This query returns the relevant replication slots
associated with all the failover-enabled subscriptions.
</para>
<para>
<programlisting>
/* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots
FROM pg_replication_slots r
WHERE r.failover AND NOT r.temporary;
slots
-------
{'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'}
(1 row)
</programlisting></para>
</sect1>
<sect1 id="logical-replication-row-filter">