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

[アーティクル]
08/15/2024

適用対象: 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などのエラーが発生する可能性があります。

Note

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

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

ネイティブ論理レプリケーションを使用することは、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 のサインイン特権を有効にして、テーブルコンテンツを確認します。
```
ALTER ROLE azure_pg_admin login;
```

論理レプリケーションの詳細については、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');

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

-- 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 を使用して手動でコピーできます。 DDL ステートメントは、pglogical.replicate_ddl_command関数を使用してプロバイダーとサブスクライバーで同時に実行できます。ここに記載されている、拡張機能のその他の制限事項に注意してください。

論理デコード

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

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

多くの場合、ストリーミングプロトコルを使用して変更を行うことをお勧めします。独自のコンシューマーやコネクタを作成したり、Debezium のようなサードパーティのサービスを使用したりできます。

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

SQL インターフェイス

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

スロットを作成します。

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 のドキュメントを参照してください。

モニター

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

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

SELECT * FROM pg_replication_slots;

値が大きくなって通常のしきい値を超えたときに通知を受け取るには、Azure Database for PostgreSQL フレキシブルサーバーのメトリック Maximum Used Transaction IDs (使用されるトランザクション ID の最大数) および Storage Used (使用済みストレージ) にアラートを設定します。

制限事項

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

重要

対応するサブスクライバーが存在しなくなった場合は、プライマリサーバーの論理レプリケーションスロットを削除する必要があります。それ以外の場合、WAL ファイルはプライマリに蓄積され、ストレージがいっぱいになります。ストレージのしきい値が特定のしきい値を超え、論理レプリケーションスロットが使用されていないとします (サブスクライバーが使用できないため)。その場合、Azure Database for PostgreSQL フレキシブルサーバーインスタンスは、その未使用の論理レプリケーションスロットを自動的に削除します。このアクションにより、蓄積された WAL ファイルが解放され、ストレージがいっぱいになったためにサーバーが使用できなくなる状況を回避できます。

次の方法で共有

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

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

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

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

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

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

pglogical 拡張機能

論理デコード

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

SQL インターフェイス

モニター

制限事項

フィードバック

その他のリソース

次の方法で共有

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

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

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

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

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

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

pglogical 拡張機能

論理デコード

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

SQL インターフェイス

モニター

制限事項

関連するコンテンツ

フィードバック

その他のリソース

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

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