5.13.4 レプリケーションテーブルの復旧

データノードにレプリケーションテーブルの更新を反映できない状態が続くと、中央管理ノードにWALが蓄積されていきます。これを解消するために、故障したデータノードに対応したレプリケーションオブジェクトを削除する必要があります。

以下に例を示します。中央管理ノードにおいて、スーパーユーザーで実行します。

レプリケーションオブジェクト(パブリケーション)にレプリケーション対象としてテーブルが追加されている場合は、pgx_detach_replication_table()を使用してレプリケーションを停止します。

-中央管理ノードにおいて、スーパーユーザーで実行
db1=# CALL pgx_detach_replication_table('public', 'tbl1', 'node1', true);
CALL

pgx_drop_replication_object()を使用して、故障したデータノードに対応するレプリケーションオブジェクトを削除します。

-同期レプリケーションを設定している場合、中央管理ノードにおいて、レプリケーションオブジェクトを非同期レプリケーションに設定
    postgresql.confでパラメータを設定
     synchronous_standby_names = ’FIRST 1 (coordinator_standby)'
    パラメータ変更を反映
     $ pg_ctl reload

-中央管理ノードにおいて、スーパーユーザーで実行
db1=# SELECT pgx_drop_replication_object('node1', true);
 pgx_drop_replication_object
-----------------------------
 t
(1 row)

復旧したデータノードが初めて起動した際に、自動的に以下の資源がデータノードに定義され、レプリケーションが開始します。

レプリケーションオブジェクト
replicatedテーブル
originalテーブルに依存する資源のうち、全ノード対象のオブジェクトとして定義された資源

レプリケーションテーブルの削除手順の詳細は“5.2.3 レプリケーションテーブルの削除”を参照してください。

各関数の詳細は、“付録B システム管理関数/プロシージャ”を参照してください。

特定のレプリケーションテーブルに対するレプリケーションが正常に動作しない場合は、一度replicatedテーブルを初期化してから、再度originalテーブルのデータを同期してください。

以下に例を示します。中央管理ノードにおいて、スーパーユーザーで実行します。

pgx_detach_replication_table()を使用して、レプリケーションの停止とreplicatedテーブルのデータ削除を実施します。このときreplicatedテーブル自体は削除されません。

db1=# CALL pgx_detach_replication_table('public', 'tbl1', 'node1');
CALL

pgx_attach_replication_table()を使用して、データの同期とレプリケーションの再開を実施します。これによりoriginalテーブルに格納されているすべてのデータがreplicatedテーブルに反映されます。

db1=# CALL pgx_attach_replication_table('public', 'tbl1', 'node1');
CALL

-同期レプリケーションを設定していた場合、中央管理ノードにおいて、レプリケーションオブジェクトを同期レプリケーションに設定
    postgresql.confでパラメータを設定
     synchronous_standby_names = ’ FIRST 2 (coordinator_standby, node1)'
    パラメータ変更を反映
     $ pg_ctl reload

各関数の詳細は、“付録B システム管理関数/プロシージャ”を参照してください。

5.13.4 レプリケーションテーブルの復旧

5.13.4.1 データノード単位の対処

5.13.4.2 テーブル単位の対処