Azure Database for PostgreSQL フレキシブルサーバーでの論理レプリケーションと論理デコード

Azure Database for PostgreSQL フレキシブルサーバーでは、次の論理データの抽出とレプリケーションの手法がサポートされています:

論理レプリケーション
1. データオブジェクトをレプリケートする、PostgreSQL のネイティブ論理レプリケーションを使用する。論理レプリケーションを使用すると、テーブルレベルのデータレプリケーションなど、データレプリケーションをきめ細かく制御できます。
2. 論理ストリーミングレプリケーションと、データベースの初期スキーマのコピー、TRUNCATE のサポート、DDL のレプリケート機能などのその他の機能を提供する pglogical 拡張機能を使用します。
先書きログ (WAL) の内容をデコードすることによって実装される論理デコード。

論理レプリケーションと論理デコードを比較する

論理レプリケーションと論理デコードには、似ている点がいくつかあります。両方とも:

Postgres からデータをレプリケートできます。
変更のソースとして先書きログ (WAL) を使用します。
データを送信するために論理レプリケーションスロットを使用します。スロットは、変更のストリームを表します。
テーブルの REPLICA IDENTITY プロパティを使用して、送信できる変更を特定します。
DDL の変更はレプリケートしません。

2 つのテクノロジには次のような違いがあります。

論理レプリケーション:

レプリケートするテーブルまたはテーブルのセットを指定できます。

論理デコード:

データベース内のすべてのテーブルから変更を抽出します。

論理レプリケーションと論理デコードの前提条件

ポータルのパラメーターページに移動します。
パラメーター wal_level を logical に設定します。
pglogical 拡張機能を使用する場合は、 shared_preload_libraries と azure.extensions パラメーターを検索し、ドロップダウンリストボックスから pglogical を選択します。
max_worker_processes パラメーターの値を 16 以上に更新します。そうしないと、 WARNING: out of background worker slotsなどの問題が発生する可能性があります。
変更を保存し、サーバーを再起動して変更を適用します。
Azure Database for PostgreSQLフレキシブルサーバーで、接続しているリソースからのネットワークトラフィックが許可されていることを確認します。
管理者ユーザーのレプリケーションのアクセス許可を付与します。
```
ALTER ROLE <adminname> WITH REPLICATION;
```
使用しているロールに、レプリケートするスキーマに対する権限があることを確認します。そうしないと、 Permission denied for schemaなどのエラーが発生する可能性があります。

注

レプリケーションユーザーを通常の管理者アカウントから分離することをお勧めします。

論理レプリケーションと論理デコードを使用する

ネイティブ論理レプリケーションを使用することは、Azure Database for PostgreSQLフレキシブルサーバーからデータをレプリケートする最も簡単な方法です。 SQL インターフェイスまたはストリーミングプロトコルを使用して、変更を使用できます。 SQL インターフェイスを使用して、論理デコードを使用して変更を使用することもできます。

ネイティブ論理レプリケーション

論理レプリケーションでは、 パブリッシャー とサブスクライバーという用語が使用 されます。

パブリッシャーは、データを送信するAzure Database for PostgreSQLフレキシブルサーバーデータベースです。
サブスクライバーは、データを受信するAzure Database for PostgreSQLフレキシブルサーバーデータベースです。

論理レプリケーションを試すために使用できるサンプルコードを次に示します。

パブリッシャーデータベースに接続します。テーブルを作成し、データをいくつか追加します。

CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
INSERT INTO basic VALUES (1, 'apple');
INSERT INTO basic VALUES (2, 'banana');

テーブルのパブリケーションを作成します。
```
CREATE PUBLICATION pub FOR TABLE basic;
```
サブスクライバーデータベースに接続します。パブリッシャーと同じスキーマでテーブルを作成します。
```
CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
```

前に作成したパブリケーションに接続するサブスクリプションを作成します。

CREATE SUBSCRIPTION sub CONNECTION 'host=<server>.postgres.database.azure.com user=<rep_user> dbname=<dbname> password=<password>' PUBLICATION pub;

これで、サブスクライバーのテーブルに対してクエリを実行できるようになります。パブリッシャーからデータを受信していることがわかります。
```
SELECT * FROM basic;
```
パブリッシャーのテーブルに行を追加し、サブスクライバーで変更を表示することができます。

データが表示されない場合は、 azure_pg_admin ロールのメンバーであるユーザーに切り替えて、テーブルの内容を確認します。

論理レプリケーションの詳細については、PostgreSQL のドキュメントを参照してください。

同じサーバー上のデータベース間で論理レプリケーションを使用する

同じAzure Database for PostgreSQLフレキシブルサーバー上の異なるデータベース間で論理レプリケーションを設定するには、実装の制限を回避するための特定のガイドラインに従ってください。現時点では、レプリケーションスロットが同じコマンド内に作成されていない場合にのみ、同じデータベースクラスターに接続するサブスクリプションを作成できます。それ以外の場合、 CREATE SUBSCRIPTION 呼び出しは、 LibPQWalReceiverReceive 待機イベントでハングします。この動作は、Postgres エンジン内の既存の制限が原因であり、今後のリリースで削除される可能性があります。

この制限を回避しながら、同じサーバー上の "ソース" データベースと "ターゲット" データベースの間で論理レプリケーションを設定するには、次の手順に従います。

最初に、ソースデータベースとターゲットデータベースの両方で同じスキーマを持つ basic という名前のテーブルを作成します。

-- Run this on both source and target databases
CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);

次に、ソースデータベースで、テーブルのパブリケーションを作成し、 pg_create_logical_replication_slot 関数を使用して論理レプリケーションスロットを個別に作成します。この方法は、通常、サブスクリプションと同じコマンドでスロットが作成されるときに発生するハング問題を防ぐのに役立ちます。 pgoutput プラグインを使用します。

-- Run this on the source database
CREATE PUBLICATION pub FOR TABLE basic;
SELECT pg_create_logical_replication_slot('myslot', 'pgoutput');

次に、ターゲットデータベースで、以前に作成したパブリケーションのサブスクリプションを作成します。 create_slotを false に設定して、Azure Database for PostgreSQLフレキシブルサーバーが新しいスロットを作成できないようにし、前の手順で作成したスロット名を指定します。コマンドを実行する前に、接続文字列のプレースホルダーを実際のデータベース資格情報に置き換えます。

-- Run this on the target database
CREATE SUBSCRIPTION sub
   CONNECTION 'dbname=<source dbname> host=<server>.postgres.database.azure.com port=5432 user=<rep_user> password=<password>'
   PUBLICATION pub
   WITH (create_slot = false, slot_name='myslot');

論理レプリケーションを設定したら、ソースデータベースの basic テーブルに新しいレコードを挿入し、ターゲットデータベースにレプリケートされることを確認して、それをテストします。

-- Run this on the source database
INSERT INTO basic SELECT 3, 'mango';

-- Run this on the target database
TABLE basic;

すべてが正しく構成されている場合は、ターゲットデータベースのソースデータベースの新しいレコードが表示され、論理レプリケーションの正常なセットアップが確認されます。

pglogical 拡張機能

プロバイダーデータベースサーバーとサブスクライバーで pglogical を構成する例を次に示します。詳細については、 pglogical 拡張機能のドキュメントを参照してください。また、前に示した前提条件のタスクを完了してください。

プロバイダーとサブスクライバーデータベースサーバーの両方のデータベースに pglogical 拡張機能をインストールします。
```
\c myDB
CREATE EXTENSION pglogical;
```
レプリケーションユーザーがサーバー管理ユーザー (サーバーを作成したユーザー) でない場合は、 azure_pg_admin ロールのユーザーメンバーシップを付与し、REPLICATION 属性と LOGIN 属性をユーザーに割り当てます。詳しくは、pglogical のドキュメントをご覧ください。
```
GRANT azure_pg_admin to myUser;
ALTER ROLE myUser REPLICATION LOGIN;
```

プロバイダー (ソースとパブリッシャー) のデータベースサーバーで、プロバイダーノードを作成します。

select pglogical.create_node( node_name := 'provider1',
dsn := ' host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');

レプリケーションセットを作成します。

select pglogical.create_replication_set('myreplicationset');

データベース内のすべてのテーブルをレプリケーションセットに追加します。
```
SELECT pglogical.replication_set_add_all_tables('myreplicationset', '{public}'::text[]);
```
別の方法として、特定のスキーマ (testUser など) から既定のレプリケーションセットにテーブルを追加することもできます。
```
SELECT pglogical.replication_set_add_all_tables('default', ARRAY['testUser']);
```

サブスクライバーのデータベースサーバーで、サブスクライバーノードを作成します。

select pglogical.create_node( node_name := 'subscriber1',
dsn := ' host=mySubscriberServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>' );

サブスクリプションを作成して、同期とレプリケーションのプロセスを開始します。

select pglogical.create_subscription (
subscription_name := 'subscription1',
replication_sets := array['myreplicationset'],
provider_dsn := 'host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=<password>');

サブスクリプションの状態を確認します。

SELECT subscription_name, status FROM pglogical.show_subscription_status();

注意事項

Pglogical では現在、自動 DDL レプリケーションはサポートされていません。 pg_dump --schema-onlyを使用して、初期スキーマを手動でコピーできます。 pglogical.replicate_ddl_command関数を使用して、プロバイダーとサブスクライバーに対して DDL ステートメントを同時に実行できます。ここに記載されている、拡張機能のその他の制限事項に注意してください。

論理デコード

ストリーミングプロトコルまたは SQL インターフェイスを介して論理デコードを使用できます。

ストリーミングプロトコル

多くの場合、ストリーミングプロトコルを使用して変更を取り込むほうが適しています。独自のコンシューマーまたはコネクタを作成することも、 Debezium などのサードパーティのサービスを使用することもできます。

pg_recvlogicalでストリーミングプロトコルを使用する例については、wal2json のドキュメント(pg_recvlogicalでストリーミングプロトコルを使用する例) を参照してください。

SQL インターフェイス

次の例では、wal2json プラグインと共に SQL インターフェイスを使用します。

スロットを作成します。

SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');

SQL コマンドを実行します。例えば次が挙げられます。

CREATE TABLE a_table (
   id varchar(40) NOT NULL,
   item varchar(40),
   PRIMARY KEY (id)
);

INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
DELETE FROM a_table WHERE id='id1';

変更を使用します。

SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');

出力は次のようになります。

{
      "change": [
      ]
}
{
      "change": [
               {
                        "kind": "insert",
                        "schema": "public",
                        "table": "a_table",
                        "columnnames": ["id", "item"],
                        "columntypes": ["character varying(40)", "character varying(40)"],
                        "columnvalues": ["id1", "item1"]
               }
      ]
}
{
      "change": [
               {
                        "kind": "delete",
                        "schema": "public",
                        "table": "a_table",
                        "oldkeys": {
                              "keynames": ["id"],
                              "keytypes": ["character varying(40)"],
                              "keyvalues": ["id1"]
                        }
               }
      ]
}

スロットの使用が完了したら、スロットを削除します。
```
SELECT pg_drop_replication_slot('test_slot');
```

論理デコードの詳細については、PostgreSQL のドキュメント「論理デコード」を参照してください。

Monitor

論理デコードは監視する必要があります。未使用のレプリケーションスロットを削除します。スロットは、変更が読み取られるまで、Postgres の WAL ログと関連するシステムカタログを保持します。サブスクライバーまたはコンシューマーが失敗した場合、または適切に構成されていない場合は、ログが消費されないまま蓄積され、ストレージがいっぱいになります。また、未使用のログによって、トランザクション ID の折り返しリスクが増加します。どちらの状況でも、サーバーを使用できなくなる可能性があります。そのため、論理レプリケーションスロットを継続的に使用する必要があります。論理レプリケーションスロットが使用されなくなった場合は、すぐにドロップしてください。

active ビューの pg_replication_slots 列は、コンシューマーがスロットに接続されているかどうかを示します。

SELECT * FROM pg_replication_slots;

[使用されたトランザクション ID の最大数] メトリックと [使用ストレージ] メトリックにアラートを設定して、値が通常のしきい値を超えたときに通知します。

制限事項

こちらに記載されているように、論理レプリケーションの制限が適用されます。
スロットと HA フェールオーバー - PostgreSQL 16 以前のバージョンでは、Azure Database for PostgreSQLで高可用性 (HA) が有効なサーバーを使用する場合、フェールオーバーイベント中に論理レプリケーションスロットは保持されません。論理レプリケーションスロットを維持し、フェールオーバー後にデータの整合性を確保するには、PG フェールオーバースロット拡張機能を使用し、 hot_standby_feedback = onなどのサポート設定を構成します。この拡張機能を有効にする方法の詳細については、ドキュメントを参照してください。

論理レプリケーションスロットのフェールオーバー対応

PostgreSQL 17 以降のバージョンでは、スロット同期がネイティブにサポートされています。適切な PostgreSQL 構成 (sync_replication_slots、 hot_standby_feedback) を有効にした場合、論理レプリケーションスロットはフェールオーバー後に自動的に保持され、拡張機能は必要ありません。

Important

対応するサブスクライバーが存在しなくなった場合は、プライマリサーバーの論理レプリケーションスロットを削除する必要があります。それ以外の場合、WAL ファイルはプライマリに蓄積され、ストレージがいっぱいになります。ストレージ使用量が 95% に達したとき、または使用可能な容量が 5 GiB 未満の場合、プライマリサーバーは自動的に読み取り専用モードに切り替わります。ストレージのしきい値が一定の制限を超え、論理レプリケーションスロットが使用されていない (サブスクライバーが使用できないため) 場合、フレキシブルサーバー Azure Database for PostgreSQL、その未使用の論理レプリケーションスロットが自動的に削除されます。このアクションにより、蓄積された WAL ファイルが解放され、ストレージがいっぱいになったためにサーバーが使用できなくなる状況を回避できます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-10