Azure Database for PostgreSQL フレキシブル サーバー インスタンスでは、次の論理データ抽出とレプリケーション手法がサポートされています。
論理レプリケーション
- データ オブジェクトをレプリケートする、PostgreSQL のネイティブ論理レプリケーションを使用する。 論理レプリケーションを使用すると、テーブル レベルのデータ レプリケーションなど、データ レプリケーションをきめ細かく制御できます。
- 論理ストリーミング レプリケーションと、データベースの初期スキーマのコピー、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');
その後、ターゲット データベースで、前に作成したパブリケーションのサブスクリプションを作成し、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;
[使用されたトランザクション ID の最大数] メトリックと [使用ストレージ] メトリックにアラートを設定して、値が通常のしきい値を超えたときに通知します。
制限事項
こちらに記載されているように、論理レプリケーションの制限が適用されます。
スロットと HA フェールオーバー - Azure Database for PostgreSQL で 高可用性 (HA) が有効なサーバーを使用する場合は、フェールオーバー イベント中に論理レプリケーション スロットが保持されないことに注意してください。 論理レプリケーション スロットを維持し、フェールオーバー後にデータの整合性を確保するには、PG フェールオーバー スロット拡張機能を使用することをお勧めします。 この拡張機能を有効にする方法の詳細については、 ドキュメントを参照してください。
重要
対応するサブスクライバーが存在しなくなった場合は、プライマリ サーバーの論理レプリケーション スロットを削除する必要があります。 それ以外の場合、WAL ファイルはプライマリに蓄積され、ストレージがいっぱいになります。 ストレージの使用率が 95% に達するか、利用可能な容量が 5 GiB 未満になると、プライマリ サーバーは自動的に読み取り専用モードに切り替わります。 ストレージのしきい値が一定の制限を超え、論理レプリケーション スロットが使用されていない場合 (使用できないサブスクライバーが原因)、Azure Database for PostgreSQL フレキシブル サーバー インスタンスによって、その未使用の論理レプリケーション スロットが自動的に削除されます。 このアクションにより、蓄積された WAL ファイルが解放され、ストレージがいっぱいになったためにサーバーが使用できなくなる状況を回避できます。