論理レプリケーションの設定確認・テーブル追加

PostgreSQlのロジカルレプリケーションは、ALTER PUBLICATION / ALTER SUBSCRIPTIONを利用して、運用開始後にテーブル追加などの変更を行えます。
（セットアップ手順については、 PostgreSQL論理レプリケーション設定で解説しています）

Publication, Subscriptionの確認

作成済のPublication、Subscriptionの情報は、対象のクラスタに接続したうえで、

SELECT * FROM pg_publication;
SELECT * FROM pg_subscription;

によって確認できます。

また、Publicationの配信対象テーブルは、

SELECT * FROM pg_publication_tables;

で表示できます。

既存のレプリケーションにテーブルを追加する

受信側にテーブルを追加作成

レプリケーションを受信してINSERTするテーブルを作成しておきます。スキーマはPublication側の定義のデッドコピー、または流用して編集したものになるでしょう。

また、レプリケーションの接続ユーザーに

GRANT SELECT ON categories TO rep_user;

のように配信テーブルへのアクセス権を付与しておきます。

Publicationにテーブル追加

ALTER PUBLICATION origindb_pub ADD TABLE categories;

で、既存のPublicationに配信対象のテーブルを追加できます。

Subscriptionリフレッシュ

受信側のデータベースに接続したうえで、

ALTER SUBSCRIPTION origin_sub1 REFRESH PUBLICATION;

すると、Publication側の設定を取得して追加したテーブルのレプリケーションが開始します。

Subscription側は設定済の接続情報で動作するため、REFRESHするだけです。

更新開始しない場合

SELECT * FROM pg_publication_tables;

や

SELECT * FROM pg_subscription_rel;

などで、追加したテーブルに対応する行が存在するか確認します。

また、配信テーブルのアクセス権がない場合には、ERROR: permission denied for relationといったエラーログが出力されます。この場合は権限追加するとリトライ時に転送が始まります。

Subscription削除

Subscriptionの削除は以下のようにDROPで実行できます。subscriptionを作成したDBに接続した状態で実行する必要があります。

DROP SUBSCRIPTION origin_sub1;

同様に、publicationも転送元DBに接続してDROP PUBLICATIONで実行可能です。

レプリカDBのバージョンアップ

PostgreSQLはメジャーバージョンアップ用のツールとして、pg_upgradeを提供しています。
pg_upgradeのレプリケーション構成サポートはv17移行で追加されますが、少なくともv16->v17までのアップグレードではレプリケーション再構築に別途操作が必要です。

バージョンアップ時にpublicationとsubscriptionオブジェクトは引き継いでいますが、レプリケーションスロットは無くなります。
Publication側は、レプリケーションスロットを旧バージョンと同じDB、同一名で再作成するとおそらく構築できます。

Subscription側は無効になっているsubscriptionを有効にしたうえで、リフレッシュすると転送が始まります。

ALTER SUBSCRIPTION origin_sub1 ENABLE;
ALTER SUBSCRIPTION origin_sub1 REFRESH PUBLICATION WITH (copy_data = false);

WITH (copy_data = false)を指定しない場合、バージョンアップ前からの再開ではなく、全データ転送を行う挙動になります。
pg_upgradeする手順では直近までのデータが入っているため、全データ転送するとコンフリクトしてエラー終了します。また、copy_data = falseは完全に同期していることを確認できなくなるケースがあります。とくに失敗したあとオプション変更して再開した場合、一部成功したトランザクションが省略され欠損行などの不一致が発生します。

よって、バージョンアップの際にSubscription側DBは再作成する方が安全でしょう。TRUNCATEした空のレプリカに全データ転送する手順でも似たような結果になります。

ロジカルレプリケーションは異なるバージョン間の転送をサポートしているため、新バージョンのレプリカを追加して動作確認したうえで旧バージョンを除去する方式もとれます。

⁋ 2018/04/10↻ 2024/12/18