To allow subscriber nodes to continue replicating data from the publisher
node even when the publisher node goes down, there must be a physical standby
corresponding to the publisher node. The logical slots on the primary server
corresponding to the subscriptions can be synchronized to the standby server by
specifying <literal>failover = true</literal> when creating subscriptions. See
<xref linkend="logicaldecoding-replication-slots-synchronization"/> for details.
Enabling the
<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>
parameter ensures a seamless transition of those subscriptions after the
standby is promoted. They can continue subscribing to publications on the
new primary server.
パブリッシャーノードがダウンした場合でも、サブスクライバーノードがパブリッシャーノードからのデータの複製を継続できるようにするには、パブリッシャーノードに対応する物理スタンバイが必要です。
サブスクリプションに対応するプライマリサーバの論理スロットは、サブスクリプションの作成時にfailover = trueを指定することで、スタンバイサーバと同期させることができます。
詳細は47.2.3を参照してください。
failoverパラメータを有効にすると、スタンバイ昇格後のサブスクリプションのシームレスな移行が保証されます。
サブスクリプションは新しいプライマリサーバ上のパブリケーションへのサブスクライブを継続できます。
Because the slot synchronization logic copies asynchronously, it is
necessary to confirm that replication slots have been synced to the standby
server before the failover happens. To ensure a successful failover, the
standby server must be ahead of the subscriber. This can be achieved by
configuring
<link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>.
スロット同期ロジックは非同期にコピーを行うため、フェイルオーバーが発生する前にレプリケーションスロットがスタンバイサーバに同期されているかを確認する必要があります。
フェイルオーバーの成功を保証するためには、スタンバイサーバはサブスクライバーよりも先行していなければいけません。
これはsynchronized_standby_slotsを設定することで実現できます。
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: 《マッチ度[70.305677]》スタンバイサーバが実際にフェイルオーバーの準備ができていることを確認するためには、次の手順に従ってすべての必要な論理レプリケーションスロットがスタンバイサーバと同期されていることを検証します。 《機械翻訳》スタンバイサーバが特定のサブスクライバーのフェイルオーバーに対して実際に準備ができていることを確認するには、次の手順に従って、そのサブスクライバーに必要なすべての論理レプリケーションスロットがスタンバイサーバに同期されていることを確認します。
On the subscriber node, use the following SQL to identify which replication slots should be synced to the standby that we plan to promote. This query will return the relevant replication slots associated with the failover-enabled subscriptions. サブスクライバーノードで、次のSQLを使用して、昇格する予定のスタンバイに同期する必要があるレプリケーションスロットを特定します。 このクエリは、フェイルオーバーが有効になっているサブスクリプションと関連付けられている、関連するレプリケーションスロットを返します。
test_sub=# SELECT
array_agg(quote_literal(s.subslotname)) AS slots
FROM pg_subscription s
WHERE s.subfailover AND
s.subslotname IS NOT NULL;
slots
-------
{'sub1','sub2','sub3'}
(1 row)
On the subscriber node, use the following SQL to identify which table synchronization slots should be synced to the standby that we plan to promote. This query needs to be run on each database that includes the failover-enabled subscription(s). Note that the table sync slot should be synced to the standby server only if the table copy is finished (See <xref linkend="catalog-pg-subscription-rel"/>). We don't need to ensure that the table sync slots are synced in other scenarios as they will either be dropped or re-created on the new primary server in those cases. サブスクライバーノードで、次のSQLを使用して、昇格する予定のスタンバイに同期する必要があるテーブル同期スロットを特定します。 このクエリは、フェイルオーバーが有効になっているサブスクリプションを持つ各データベースで実行する必要があります。 テーブル同期スロットは、テーブル同期が終了している場合にのみ同期されることに注意してください（51.55を参照）。 その他の場合では、テーブル同期スロットが同期されることを保証する必要はありません。これらは破棄されるか、新しいプライマリサーバで再作成されるためです。
test_sub=# SELECT
array_agg(quote_literal(slot_name)) AS slots
FROM
(
SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_identifier) AS slot_name
FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscription s
WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover
);
slots
-------
{'pg_16394_sync_16385_7394666715149055164'}
(1 row)
Check that the logical replication slots identified above exist on the standby server and are ready for failover. 上記で特定した論理レプリケーションスロットがスタンバイに存在し、フェイルオーバーの準備ができていることを確認します。
test_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');
slot_name | failover_ready
--------------------------------------------+----------------
sub1 | t
sub2 | t
sub3 | t
pg_16394_sync_16385_7394666715149055164 | t
(4 rows)
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 on the new
primary server.
《マッチ度[93.013100]》すべてのスロットがスタンバイサーバに存在し、上記のSQLクエリの結果（failover_ready）が真である場合、既存のサブスクリプションは、新しいプライマリサーバ上のパブリケーションへのサブスクライブを継続できます。
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. 《機械翻訳》前述のプロシージャの最初の2つのステップは、PostgreSQLサブスクライバーを対象としています。 サブスクライバースロットの完全なリストを取得するには、フェイルオーバーの後に指定スタンバイがサービスを提供する各レプリケーションノードでこれらのステップを実行することをお薦めします。 このリストは、ステップ3から保証フェイルオーバーの準備状況で検証できます。 一方、非PostgreSQLサブスクライバーは、独自の方法を使用して、それぞれのサブスクリプションで使用されるレプリケーションスロットを識別できます。
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. 《機械翻訳》計画フェイルオーバー中などの場合は、すべての加入者が、PostgreSQLまたは非PostgreSQLであるかどうかにかかわらず、特定のレプリケーションまでフェイルオーバーの後にスタンバイサーバを続行できることを確認する必要があります。 このような場合は、次のSQL、代わりを使用して前述の最初の2つの手順を実行し、プライマリのどのレプリケーションスロットを販促対象のスタンバイに同期化する必要があるかを識別します。 この問い合わせは、すべてのフェイルオーバー対応の登録に関連付けられたレプリケーションスロットを戻します。
/* 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)