Aurora での PostgreSQL 論理的なレプリケーションの使用 - Amazon Aurora
論理レプリケーションの設定論理レプリケーションをオフにする論理レプリケーションライトスルーキャッシュのモニタリング論理スロットの管理 例: 論理レプリケーションの使用 例: Aurora PostgreSQL と AWS DMS を使用した論理レプリケーション

Aurora での PostgreSQL 論理的なレプリケーションの使用

Aurora PostgreSQL DB クラスターで PostgreSQL の論理レプリケーション機能を使用することで、データベースインスタンス全体ではなく、個々のテーブルをレプリケートおよび同期できます。論理レプリケーションでは、パブリケーションおよびサブスクリプションモデルを使用して、ソースからの変更を 1 人または複数の受信者にレプリケートします。これは、PostgreSQL のログ先行書き込み (WAL) の変更レコードを使用することで動作します。送信元 (パブリッシャー) は、指定されたテーブルの WAL データを 1 人または複数の受信者 (サブスクライバー) に送信します。これによって変更がレプリケートされ、サブスクライバーのテーブルとパブリッシャーのテーブルの同期を維持できます。パブリッシャーによる一連の変更は、パブリケーションを使用して識別します。サブスクライバーは、パブリッシャーのデータベースとそのパブリケーションへの接続を定義するサブスクリプションを作成することによって変更を取得できます。レプリケーションスロットは、この方式によってサブスクリプションの進行状況を追跡するために使用されるメカニズムです。

Aurora PostgreSQL DB クラスターでは、WAL レコードは Aurora ストレージに保存されます。論理レプリケーションシナリオでパブリッシャーとして機能する Aurora PostgreSQL DB クラスターは、Aurora ストレージから WAL データを読み込み、デコードしてサブスクライバーに送信し、そのインスタンスのテーブルに変更を適用できるようにします。パブリッシャーでは、論理デコーダーを使用してデータをデコードすることでサブスクライバーが使用できるようにします。デフォルトでは、Aurora PostgreSQL DB クラスターはデータを送信する際にネイティブ PostgreSQL pgoutput プラグインを使用します。他の論理デコーダーも使用できます。例えば、Aurora PostgreSQL は WAL データを JSON に変換する wal2json プラグインもサポートしています。

Aurora PostgreSQL バージョン 14.5、13.8、12.12、11.17 以降、Aurora PostgreSQL は PostgreSQL の論理レプリケーションプロセスをライトスルーキャッシュで強化してパフォーマンスを向上させています。WAL トランザクションログは、ディスク I/O の量、つまり論理デコード中に Aurora ストレージから読み取る量を減らすために、ローカルでバッファにキャッシュされます。Aurora PostgreSQL DB クラスターの論理レプリケーションを使用する場合は常に、ライトスルーキャッシュがデフォルトで使用されます。Aurora には、キャッシュの管理に使用できる機能がいくつか用意されています。詳細については、「Aurora PostgreSQL 論理レプリケーションライトスルーキャッシュの管理」を参照してください。

論理レプリケーションは、現在の Aurora PostgreSQL のすべてのバージョンでサポートされています。詳細については、「Aurora PostgreSQL リリースノート」の「Amazon Aurora PostgreSQL の更新」を参照してください。

注記

PostgreSQL 10 で導入されたネイティブの PostgreSQL 論理レプリケーション機能に加えて、Aurora PostgreSQL は pglogical エクステンションもサポートしています。詳細については、「pglogical を使用してインスタンス間でデータを同期する」を参照してください。

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

次のトピックでは、Aurora PostgreSQL DB クラスター間の論理レプリケーションの設定方法について説明します。

Aurora PostgreSQL DB クラスターの論理レプリケーションの設定

論理レプリケーションの設定には rds_superuser 権限が必要です。以下で説明する手順のように、Aurora PostgreSQL DB クラスターは、必要なパラメータを設定できるように、カスタム DB クラスターパラメータグループを使用するように設定する必要があります。詳細については、「DB クラスターパラメータグループを使用する」を参照してください。

Aurora PostgreSQL DB クラスターに PostgreSQL 論理レプリケーションを設定するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Aurora PostgreSQL DB cluster] (Aurora PostgreSQL DB クラスター) を選択します。

  3. [Configuration] (設定) タブを開きます。インスタンスの詳細の中から、タイプの DB クラスターパラメーターグループとのパラメーターグループのリンクを見つけます。

  4. リンクを選択して、Aurora PostgreSQL DB クラスターに関連するカスタムパラメータを開きます。

  5. [Parameters] (パラメータ) 検索フィールドに rds と入力し、rds.logical_replication パラメータを検索します。このパラメータのデフォルト値は 0 です。つまり、デフォルトではオフになっています。

  6. [Edit parameters] (パラメータの編集) を選択してプロパティ値にアクセスし、次にセレクタから 1 を選択して機能をオンにします。予想される使用状況に応じて、次のパラメータ設定の変更が必要になる場合があります。ただし、多くの場合はデフォルト値で十分です。

    • max_replication_slots — このパラメータには、最低でも論理レプリケーションのパブリケーションとサブスクリプションの合計予定数以上の値を設定します。AWS DMS を使用している場合、このパラメータには、クラスターからの変更データ取得タスクの予定数に、論理レプリケーションのパブリケーションとサブスクリプションを加えたものと最低でも同じ値を設定する必要があります。

    • max_wal_senders および max_logical_replication_workers - これらのパラメータには、アクティブにする予定の論理レプリケーションスロットの最小数、または変更データ取得用のアクティブな AWS DMS タスクの数以上の値を設定します。論理レプリケーションスロットを非アクティブにしておくと、バキュームによってテーブルから古いタプルを削除できないため、レプリケーションスロットをモニタリングして、必要に応じて非アクティブなスロットを削除することをお勧めします。

    • max_worker_processes – このパラメータには、最低でも max_logical_replication_workers、autovacuum_max_workers、max_parallel_workers の合計と同じ値を設定してください。小規模な DB インスタンスクラスでは、バックグラウンドのワーカープロセスがアプリケーションのワークロードに影響を与える可能性があるため、max_worker_processes をデフォルト値よりも高い値を設定する場合はデータベースのパフォーマンスをモニタリングしてください。(デフォルト値は GREATEST(${DBInstanceVCPU*2},8} の結果であり、つまり、デフォルトでは 8 または DB インスタンスクラスの CPU 相当量の 2 倍のどちらか大きい方になります)。

    注記

    ユーザー定義の DB パラメータグループのパラメータ値は変更できますが、デフォルトの DB パラメータグループのパラメータ値を変更することはできません。

  7. [Save changes] (変更の保存) をクリックします。

  8. Aurora PostgreSQL DB クラスターのライターインスタンスを再起動して、変更を有効にします。Amazon RDS コンソールで、クラスターのプライマリ DB インスタンスを選択し、[Actions] (アクション) メニューから [Reboot] (再起動) を選択します。

  9. インスタンスが使用可能になると、次のように論理レプリケーションがオンになっていること確認できます。

    1. psql を使用して、Aurora PostgreSQL DB クラスターのライターインスタンスに接続します。

      psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb

    2. 次のコマンドを使用して、論理レプリケーションが有効になっていることを確認します。

      labdb=> SHOW rds.logical_replication;
 rds.logical_replication
-------------------------
 on
(1 row)

    3. wal_level が logical に設定されていることを確認してください。

      labdb=> SHOW wal_level;
  wal_level
-----------
 logical
(1 row)

論理レプリケーションを使用して、ソースの Aurora PostgreSQL DB クラスターからの変更とデータベーステーブルの同期を維持させる例については、「例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用」を参照してください。

論理レプリケーションをオフにする

レプリケーションタスクが完了したら、レプリケーションプロセスを停止し、レプリケーションスロットを削除して論理レプリケーションをオフにする必要があります。スロットを削除する前に、そのスロットが不要になったことを確認します。アクティブなレプリケーションスロットは削除できません。

論理レプリケーションをオフにするには

  1. すべてのレプリケーションスロットを削除します。

    すべてのレプリケーションスロットを削除するには、パブリッシャーに接続して以下の SQL コマンドを実行します。

    SELECT pg_drop_replication_slot(slot_name)
  FROM pg_replication_slots
 WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

    そのコマンドを実行する際、レプリケーションスロットをアクティブにすることはできません。

  2. 「Aurora PostgreSQL DB クラスターの論理レプリケーションの設定」で説明したように、パブリッシャーに関連するカスタム DB クラスターのパラメータグループを変更し、rds.logical_replication パラメータを 0 に設定します。

    カスタムパラメータグループの詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

  3. rds.logical_replication パラメータの変更を有効にするには、パブリッシャーの Aurora PostgreSQL DB クラスターを再起動します。

Aurora PostgreSQL 論理レプリケーションライトスルーキャッシュの管理

デフォルトでは、Aurora PostgreSQL バージョン 14.5、13.8、12.12、11.17 以降は、ライトスルーキャッシュを使用して論理レプリケーションのパフォーマンスを向上させます。ライトスルーキャッシュがない場合、Aurora PostgreSQL はネイティブ PostgreSQL 論理レプリケーションプロセスの実装に Aurora ストレージレイヤーを使用します。そのためには、WAL データをストレージに書き込み、ストレージからデータを読み戻してデコードし、ターゲット (サブスクライバー) に送信 (複製) します。このため、Aurora PostgreSQL DB クラスターの論理レプリケーション中にボトルネックが発生する可能性があります。

ライトスルーキャッシュにより、Aurora ストレージレイヤーを使用する必要性が減ります。Aurora PostgreSQL は、常に Aurora ストレージレイヤーからの書き込みと読み取りを行う代わりに、バッファを使用して論理 WAL ストリームをキャッシュするため、レプリケーションプロセス中に常にディスクからプルする必要がありません。このバッファは、論理レプリケーションで使用される PostgreSQL ネイティブキャッシュであり、Aurora PostgreSQL DB クラスターのパラメータで rds.logical_wal_cache として識別されます。デフォルトでは、このキャッシュは Aurora PostgreSQL DB クラスターのバッファキャッシュ設定 (shared_buffers) の 32 分の 1 を使用しますが、64 KB より少ないことはなく、または 1 つの WAL セグメントのサイズ (通常は 16 MB) を超えません。

Aurora PostgreSQL DB クラスターで論理レプリケーションを使用する場合 (ライトスルーキャッシュをサポートするバージョンの場合)、キャッシュヒット率をモニタリングして、ユースケースでの機能を確認できます。そのためには、次の例に示すように、psql を使用して Aurora PostgreSQL DB クラスターの書き込みインスタンスに接続し、次に Aurora 関数 aurora_stat_logical_wal_cache を使用します。

SELECT * FROM aurora_stat_logical_wal_cache();

関数は、次のような出力を返します。

name       | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183      | 24        | 0          | 24        | 100.00%  | 2022-08-05 17:39...
test_slot2 |            | 1         | 0          |  1        | 100.00%  | 2022-08-05 17:34...
(2 rows)

last_reset_timestamp 値は読みやすいように短くされています。この関数の詳細については、「aurora_stat_logical_wal_cache」を参照してください。

Aurora PostgreSQL には、ライトスルーキャッシュをモニタリングするための次の 2 つの関数が用意されています。

  • aurora_stat_logical_wal_cache 関数 - リファレンスドキュメントについては、「aurora_stat_logical_wal_cache」を参照してください。

  • aurora_stat_reset_wal_cache 関数 - リファレンスドキュメントについては、「aurora_stat_reset_wal_cache」を参照してください。

自動調整された WAL キャッシュサイズがワークロードに十分でない場合は、カスタム DB クラスターパラメータグループのパラメータを変更することによって、rds.logical_wal_cache の値を手動で変更できます。32kB 未満の正の値は 32kB として扱われることに注意してください。wal_buffers の詳細については、PostgreSQL ドキュメントの「ログ先行書き込み」を参照してください。

Aurora PostgreSQL の論理スロットの管理

ストリーミングアクティビティは、pg_replication_origin_status ビューにキャプチャされます。このビューの内容を確認するには、次に示す pg_show_replication_origin_status() 関数が使用できます。

SELECT * FROM pg_show_replication_origin_status();

次の SQL クエリを使用すると、論理スロットのリストを取得できます。

SELECT * FROM pg_replication_slots;

論理スロットを削除するには、次のコマンドに示すように、スロットの名前を指定して pg_drop_replication_slot を使用します。

SELECT pg_drop_replication_slot('test_slot');

例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用

以下の手順では、2 つの Aurora PostgreSQL DB クラスター間で論理レプリケーションを開始する方法を示しています。「Aurora PostgreSQL DB クラスターの論理レプリケーションの設定」で説明したように、パブリッシャーとサブスクライバーの両方が、論理レプリケーション用に設定されている必要があります。

パブリッシャーとして指定されている Aurora PostgreSQL DB クラスターでも、レプリケーションスロットへのアクセスを許可する必要があります。そのためには、Amazon VPC サービスに基づいて Aurora PostgreSQL DB クラスターの仮想パブリッククラウド (VPC) に関連付けられているセキュリティグループを変更します。サブスクライバーの VPC に関連付けられているセキュリティグループをパブリッシャーのセキュリティグループに追加することで、インバウンドアクセスを許可します。詳細については、「Amazon VPC ユーザーガイド」の「セキュリティグループを使用してリソースへのトラフィックを制御する」を参照してください。

これらの準備手順が完了したら、次の手順で説明されているように、パブリッシャーには PostgreSQL の CREATE PUBLICATION コマンドを、サブスクライバーには CREATE SUBSCRIPTION コマンドを使用できます。

2 つの Aurora PostgreSQL DB クラスター間で論理レプリケーションを開始するには

これらの手順では、Aurora PostgreSQL DB クラスターに、サンプルテーブルを作成するデータベースを含むライターインスタンスがあることを前提としています。

  1. パブリッシャーとしての Aurora PostgreSQL DB クラスター

    1. 次の SQL ステートメントを使用してテーブルを作成します。

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. 次の SQL ステートメントを使用して、パブリッシャーデータベース内にデータを挿入します。

      INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));

    3. 次の SQL ステートメントを使用して、テーブルにデータが存在することを確認します。

      SELECT count(*) FROM LogicalReplicationTest;

    4. 次のように、CREATE PUBLICATION ステートメントを使用してこのテーブルのパブリケーションを作成します。

      CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;

  2. サブスクライバーとしての Aurora PostgreSQL DB クラスター

    1. 次のように、パブリッシャーで作成したものと同じ LogicalReplicationTest テーブルをサブスクライバーに作成します。

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. このテーブルが空であることを確認します。

      SELECT count(*) FROM LogicalReplicationTest;

    3. サブスクリプションを作成して、パブリッシャーから変更を取得します。パブリッシャーの Aurora PostgreSQL DB クラスターについて、次の詳細を使用する必要があります。

      • host (ホスト) - パブリッシャーである Aurora PostgreSQL DB クラスターのライター DB インスタンス。

      • ポート - 書き込み DB インスタンスがリッスンするポート。PostgreSQL のデフォルト値は 5432 です。

      • dbname (データベース名) – データベースの名前。

      CREATE SUBSCRIPTION testsub CONNECTION 
   'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password' 
   PUBLICATION testpub;
      注記

      セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。

      サブスクリプションを作成すると、論理的なレプリケーションスロットがパブリッシャーで作成されます。

    4. この例で、初期のデータがサブスクライバーにレプリケートされていることを確認するには、サブスクライバーデータベースで次の SQL ステートメントを使用します。

      SELECT count(*) FROM LogicalReplicationTest;

パブリッシャーの以降のすべての変更がサブスクライバーにレプリケートされます。

論理レプリケーションはパフォーマンスに影響を与えます。レプリケーションタスクが完了したら、論理レプリケーションをオフにすることをお勧めします。

例: Aurora PostgreSQL と AWS Database Migration Service を使用した論理レプリケーション

AWS Database Migration Service 「AWS DMS」 を使用してデータベースまたはその一部をレプリケートできます。AWS DMS を使用して、Aurora PostgreSQL データベースから、別のオープンソースデータベースまたは商用データベースにデータを移行させます。AWS DMS の詳細については、『AWS Database Migration Service ユーザーガイド』を参照してください。

次の例では、Aurora PostgreSQL データベースからの (パブリッシャーとしての) 論理的なレプリケーションを設定し、次に移行のために AWS DMS を使用する方法を示します。この例では、「例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用」で作成したのと同じパブリッシャーおよびサブスクライバーを使用しています。

AWS DMS で論理的なレプリケーションを設定するには、Amazon RDS のパブリッシャーとサブスクライバーに関する詳細が必要です。特に、パブリッシャーの書き込み DB インスタンスとサブスクライバーの DB インスタンスに関する詳細が必要です。

パブリッシャーの書き込み DB インスタンスについては以下の情報を取得します。

  • 仮想プライベートクラウド (VPC) の識別子

  • サブネットグループ

  • アベイラビリティーゾーン (AZ)

  • VPC セキュリティグループ

  • DB インスタンス ID

サブスクライバーの DB インスタンスについては以下の情報を取得します。

  • DB インスタンス ID

  • 出典エンジン

Aurora PostgreSQL での論理的なレプリケーションに AWS DMS を使用するには

  1. AWS DMS を使用するようにパブリッシャーデータベースを準備します。

    これを行うには、PostgreSQL 10.x 以降のデータベースで、AWS DMS ラッパー関数をパブリッシャーデータベースに適用する必要があります。このステップと以降のステップの詳細については、AWS Database Migration Service ユーザーガイドの「AWS DMS のソースとして PostgreSQL バージョン 10.x 以降を使用する」を参照してください。

  2. AWS Management Console にサインインして、AWS DMS で https://console.aws.amazon.com/dms/v2 コンソールを開きます。右上で、パブリッシャーとサブスクライバーがある同じ AWS リージョンを選択します。

  3. AWS DMS レプリケーションインスタンスを作成します。

    パブリッシャーの書き込み DB インスタンスと同じ値を選択します。これらには、以下の設定が含まれます。

    • 「VPC」 で、書き込み DB インスタンスと同じ VPC を選択します。

    • 「Replication Subnet Group (レプリケーションのサブネットグループ)」 で、書き込み DB インスタンスと同じ値のサブネットグループを選択します。必要に応じて新規に作成してください。

    • 「アベイラビリティーゾーン」 で、書き込み DB インスタンスと同じゾーンを選択します。

    • 「VPC セキュリティグループ」 で、書き込み DB インスタンスと同じグループを選択します。

  4. 出典の AWS DMS エンドポイントを作成します。

    次の設定を使用して、パブリッシャーを出典エンドポイントとして指定します。

    • 「Endpoint type (エンドポイントタイプ)」 で 「Source endpoint (出典エンドポイント)」を選択します。

    • 「Select RDS DB Instance (RDS DB インスタンスの選択)」 を選択します。

    • 「RDS Instance (RDS インスタンス)」で、パブリッシャーの書き込み DB インスタンスの DB 識別子を選択します。

    • 「Source engine (出典エンジン)」 で 「postgres」 を選択します。

  5. ターゲットの AWS DMS エンドポイントを作成します。

    次の設定を使用して、サブスクライバーをターゲットエンドポイントとして指定します。

    • 「Endpoint type (エンドポイントタイプ)」 で 「Target endpoint (ターゲットエンドポイント)」 を選択します。

    • [Select RDS DB Instance (RDS DB インスタンスの選択)] を選択します。

    • [RDS Instance (RDS インスタンス)] で、サブスクライバーの DB インスタンスの DB 識別子を選択します。

    • [Source engine (出典エンジン)] の値を選択します。例えば、サブスクライバーが RDS PostgreSQL データベースの場合は、[postgres] を選択します。サブスクライバーが Aurora PostgreSQL データベースである場合は、[aurora-postgresql] を選択します。

  6. AWS DMS データベース移行タスクを作成します。

    データベース移行タスクを使用して、移行するデータベーステーブルを指定し、ターゲットスキーマを使用してデータをマッピングして、ターゲットデータベースで新しいテーブルを作成します。少なくとも、[Task configuration (タスクの設定)] で以下の設定を使用します。

    • [Replication instance (レプリケーションインスタンス)] で、前のステップで作成したレプリケーションインスタンスを選択します。

    • [Source database endpoint (出典データベースエンドポイント)] で、前のステップで作成したパブリッシャー出典を選択します。

    • [Target database endpoint (ターゲットデータベースエンドポイント)] で、前のステップで作成したサブスクライバーターゲットを選択します。

    タスクの残りの詳細は、移行プロジェクトに応じて異なります。DMS タスクのすべての詳細を指定する方法については、AWS Database Migration Service ユーザーガイドの「AWS DMS タスクの使用」を参照してください。

AWS DMS は、タスクを作成した後で、パブリッシャーからサブスクライバーへのデータの移行を開始します。