Amazon RDS for PostgreSQL でのリードレプリカの使用 - Amazon Relational Database Service
リードレプリカの論理デコードPostgreSQL でのリードレプリカの制限PostgreSQL でのリードレプリカの設定カスケードリードレプリカの使用クロスリージョンカスケーディングリードレプリカの作成RDS for PostgreSQL のバージョンが異なる場合のレプリケーションの仕組みレプリケーションプロセスのモニタリングとチューニングRDS for PostgreSQL リードレプリカのトラブルシューティング

Amazon RDS for PostgreSQL でのリードレプリカの使用

リードレプリカをインスタンスに追加することによって、Amazon RDS for PostgreSQL DB インスタンスの読み取りをスケーリングできます。他の Amazon RDS データベースエンジンと同様、RDS for PostgreSQL は PostgreSQL のネイティブレプリケーションメカニズムを使用して、ソース DB の更新がリードレプリカに反映されるようにします。リードレプリカと Amazon RDS の概要については、「DB インスタンスのリードレプリカの操作」を参照してください。

RDS for PostgreSQL でのリードレプリカの使用に関する特定の情報については、以下を参照してください。

リードレプリカの論理デコード

RDS for PostgreSQL は、PostgreSQL 16.1 を使用したスタンバイからの論理レプリケーションをサポートしています。これにより、読み取り専用スタンバイから論理デコードを作成し、プライマリ DB インスタンスの負荷を軽減できます。複数のシステム間でデータを同期する必要があるアプリケーションで可用性を高めることができます。この機能により、データウェアハウスとデータ分析のパフォーマンスが向上します。

また、特定のスタンバイのレプリケーションスロットは、そのスタンバイのプライマリへの昇格を保持します。つまり、プライマリ DB インスタンスのフェイルオーバーやスタンバイから新しいプライマリへの昇格の際にも、レプリケーションスロットは保持され、以前のスタンバイサブスクライバーには影響しません。

リードレプリカに論理デコードを作成するには

  1. 論理レプリケーションを有効にする – スタンバイで論理デコードを作成するには、ソース DB インスタンスとその物理レプリカで論理レプリケーションを有効にする必要があります。詳細については、「PostgreSQL でのリードレプリカの設定」を参照してください。

    • 新しく作成された RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには – 新しい DB カスタムパラメータグループを作成し、静的パラメータ rds.logical_replication を 1 に設定します。次に、この DB パラメータグループをソース DB インスタンスとその物理リードレプリカに関連付けます。詳細については、「Amazon RDS で DB パラメータグループを DB インスタンスに関連付ける」を参照してください。

    • 既存の RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには — ソース DB インスタンスとその物理リードレプリカの DB カスタムパラメータグループを変更して、静的パラメータ rds.logical_replication を 1 に設定します。詳細については、「Amazon RDS の DB パラメータグループのパラメータの変更」を参照してください。

    注記

    これらのパラメータの変更を適用するには、DB インスタンスを再起動する必要があります。

    次のクエリを使用して、ソース DB インスタンスとその物理リードレプリカの wal_level および rds.logical_replication の値を確認できます。

    Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
            
 name                    | setting 
-------------------------+---------
 rds.logical_replication | on
 wal_level               | logical
(2 rows)

  2. ソースデータベースにテーブルを作成する – ソース DB インスタンスのデータベースに接続します。詳細については、「PostgreSQL データベースエンジンを実行する DB インスタンスへの接続」を参照してください。

    次のクエリを使用して、ソースデータベースにテーブルを作成し、値を挿入します。

    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
    Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000

  3. ソーステーブルのパブリケーションを作成する – 次のクエリを使用して、ソース DB インスタンスにテーブルのパブリケーションを作成します。

    Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION

    SELECT クエリを使用して、ソース DB インスタンスと物理リードレプリカインスタンスの両方で作成されたパブリケーションの詳細を確認します。

    Postgres=>SELECT * from pg_publication;
             
oid    | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
 16429 | testpub |    16413 | f            | t         | t         | t         | t           | f
(1 row)

  4. 論理レプリカインスタンスからサブスクリプションを作成する – 論理レプリカインスタンスとして別の RDS for PostgreSQL DB インスタンスを作成します。この論理レプリカインスタンスが物理リードレプリカインスタンスにアクセスできるように、VPC が正しく設定されていることを確認します。詳細については、「Amazon VPC と Amazon RDS」を参照してください。ソース DB インスタンスがアイドル状態の場合、接続の問題が発生し、プライマリがデータをスタンバイに送信しない可能性があります。

    Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port 
                dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE:  created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE

    SELECT クエリを使用して、論理レプリカインスタンスのサブスクリプションの詳細を確認します。

    Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
            
oid    | subname | subenabled | subslotname | subpublications 
-------+---------+------------+-------------+-----------------
 16429 | testsub | t          | testsub     | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
 count 
-------
 10000
(1 row)

  5. 論理レプリケーションスロットの状態を確認する – ソース DB インスタンスの物理レプリケーションスロットのみを表示できます。

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name                                    | slot_type | confirmed_flush_lsn 
---------------------------------------------+-----------+---------------------
 rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical  | 
(1 row)

    ただし、リードレプリカインスタンスでは、アプリケーションが論理変更をアクティブに消費すると、論理レプリケーションスロットと confirmed_flush_lsn 値の変化を確認できます。

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/500002F0
(1 row)
    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/5413F5C0
(1 row)

PostgreSQL でのリードレプリカの制限

PostgreSQL リードレプリカの制限は以下のとおりです。

注記

PostgreSQL バージョン 12 以前を実行している RDS for PostgreSQL マルチ AZ およびシングル AZ DB インスタンスのリードレプリカは、60～90 日間のメンテナンスウィンドウ中にパスワードのローテーションを適用するために自動的に再起動されます。スケジュールされた再起動前にレプリカからソースへの接続が切断された場合も、レプリケーションを再開するためにインスタンスは再起動されます。

  • PostgreSQL リードレプリカは読み取り専用です。リードレプリカは書き込み可能な DB インスタンスではありませんが、リードレプリカをスタンドアロンの RDS for PostgreSQL DB インスタンスに昇格させることができます。ただし、このプロセスを元に戻すことはできません。

  • RDS for PostgreSQL DB インスタンスで、14.1 より前のバージョンの PostgreSQL が実行されている場合、別のリードレプリカからリードレプリカを作成することはできません。RDS for PostgreSQL でカスケードリードレプリカがサポートされているのは、RDS for PostgreSQL バージョン 14.1 以降のリリースのみです。詳細については、「RDS for PostgreSQL でのカスケードリードレプリカの使用」を参照してください。

  • PostgreSQL リードレプリカを昇格させると、書き込み可能な DB インスタンスになります。これにより、ソース DB インスタンスからの先書きログ (WAL) ファイルの受信が停止し、読み取り専用インスタンスではなくなります。RDS for PostgreSQL DB インスタンスと同様に、昇格した DB インスタンスから新しいリードレプリカを作成できます。詳細については、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。

  • レプリケーションチェーン内 (一連のカスケードリードレプリカ) から PostgreSQL リードレプリカを昇格させると、既存のダウンストリームリードレプリカは、昇格したインスタンスから WAL ファイルを自動的に受信し続けます。詳細については、「RDS for PostgreSQL でのカスケードリードレプリカの使用」を参照してください。

  • ソース DB インスタンスでユーザートランザクションが実行されていない場合、関連付けられた PostgreSQL リードレプリカは、最長 5 分のレプリケーションの遅延を報告します。レプリカラグは currentTime - lastCommitedTransactionTimestamp として計算され、トランザクションが処理されていない場合、先書きログ (WAL) セグメントが切り替わるまでの一定期間、レプリカラグの値が増加することを意味します。デフォルトでは、RDS for PostgreSQL は 5 分ごとに WAL セグメントを切り替えます。これにより、トランザクションレコードが生成され、報告されるラグが減少します。

  • RDS for PostgreSQL 14.1 より前のバージョンの PostgreSQL リードレプリカでは、自動バックアップをオンにすることはできません。リードレプリカの自動バックアップは、RDS for PostgreSQL 14.1 以降のバージョンでのみサポートされます。RDS for PostgreSQL 13 以前のバージョンでバックアップが必要な場合は、リードレプリカのスナップショットを作成します。

  • リードレプリカでは、ポイントインタイムリカバリ (PITR) はサポートされません。PITR は、リードレプリカではなく、プライマリ (ライター) インスタンスでのみ使用できます。詳細については、「Amazon RDS の DB インスタンスを特定の時点に復元する」を参照してください。

PostgreSQL でのリードレプリカの設定

RDS for PostgreSQL では、PostgreSQL ネイティブストリーミングレプリケーションを使用して、ソース DB インスタンスの読み取り専用コピーを作成します。このリードレプリカ DB インスタンスは、非同期的に作成されたソース DB インスタンスの物理レプリカです。これは、先書きログ (WAL) のデータをソース DB インスタンスからリードレプリカに送信する特別な接続によって作成されます。詳細については、PostgreSQL ドキュメントの「Streaming Replication」(ストリーミングレプリケーション) を参照してください。

ソース DB インスタンスでデータベースの変更が行われた場合、PostgreSQL は、非同期的に安全な接続に変更をストリーミングします。クライアントアプリケーションからソース DB インスタンスまたはリードレプリカへの通信を暗号化するには、ssl パラメータを 1 に設定します。詳細については、「PostgreSQL DB インスタンスで SSL を使用する」を参照してください。

PostgreSQL はレプリケーションロールを使用して、ストリーミングレプリケーションを実行します。このロールには特権がありますが、データの変更には使用できません。PostgreSQL ではレプリケーション処理に 1 つのプロセスを使用します。

ソース DB インスタンスのオペレーションとユーザーに影響を与えることなく、PostgreSQL リードレプリカを作成できます。Amazon RDS では、サービスに影響を与えることなく、ソース DB インスタンスとリードレプリカに必要なパラメータとアクセス許可を設定できます。ソース DB インスタンスのスナップショットが取得され、このスナップショットを使用してリードレプリカが作成されます。将来のある時点でリードレプリカを削除しても、停止は発生しません。

同一リージョン内の 1 つの ソース DB インスタンスから、最大 15 個のリードレプリカを作成できます。さらに、RDS for PostgreSQL 14.1 以降では、ソース DB インスタンスから最大 3 層のリードレプリカのチェーン (カスケード) を作成することもできます。詳細については、「RDS for PostgreSQL でのカスケードリードレプリカの使用」を参照してください。いずれの場合も、ソース DB インスタンスで自動バックアップを設定する必要があります。これを行うには、DB インスタンスのバックアップ保持期間を 0 以外の値に設定します。詳細については、「リードレプリカの作成」を参照してください。

RDS for PostgreSQL DB インスタンス用のリードレプリカをソース DB インスタンスとして同じ AWS リージョン 内に作成できます。これは、リージョン内レプリケーションと呼ばれます。また、ソース DB インスタンスと異なる AWS リージョン にリードレプリカを作成することもできます。これは、クロスリージョンレプリケーションと呼ばれます。クロスリージョンリードレプリカの設定に関する詳細は、「別の AWS リージョン でのリードレプリカの作成」を参照してください。「RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み」で説明されているように、リージョン内およびクロスリージョンのレプリケーションプロセスをサポートするさまざまなメカニズムは、RDS for PostgreSQL のバージョンによって若干異なります。

レプリケーションを効率的に実行するには、各リードレプリカにソース DB インスタンスと同程度のコンピューティングリソースとストレージリソースが必要です。ソース DB インスタンスをスケールした場合は、リードレプリカもスケールする必要があります。

互換性のないパラメータがあり、それが原因でリードレプリカを起動できない場合、Amazon RDS によってリードレプリカのパラメータ値が上書きされます。例えば、リードレプリカよりもソース DB インスタンスの方が max_connections パラメータ値が高いとします。この場合は、Amazon RDS によって、リードレプリカのパラメータがソース DB インスタンスのパラメータと同じ値になるように更新されます。

RDS for PostgreSQL リードレプリカは、ソース DB インスタンスの外部データラッパー (FDW) を介して利用可能な外部データベースにアクセスできます。例えば、RDS for PostgreSQL DB インスタンスで、mysql_fdw ラッパーを使用して RDS for MySQL のデータにアクセスするとします。その場合、リードレプリカはそのデータにもアクセスできます。サポートされているその他の FDW には、oracle_fdw、postgres_fdw、および tds_fdw があります。詳細については、「Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する」を参照してください。

マルチ AZ 構成で RDS for PostgreSQL リードレプリカを使用する

リードレプリカは、シングル AZ DB インスタンスから、またはマルチ AZ DB インスタンスから作成できます。重要なデータの耐久性と可用性を高めるために、1 つのスタンバイレプリカを備えたマルチ AZ 配置を使用できます。スタンバイレプリカは、ソース DB がフェイルオーバーした場合にワークロードを引き受けることができる専用のリードレプリカです。スタンバイレプリカを使用して読み取りトラフィックを処理することはできません。ただし、トラフィックの多いマルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置についての詳細は、「Amazon RDS のマルチ AZ DB インスタンスデプロイ」を参照してください。

マルチ AZ 配置のソース DB インスタンスがスタンバイにフェイルオーバーすると、関連付けられているリードレプリカがスタンバイ (現在はプライマリ) をレプリケーションのソースとして使用するよう切り替わります。以下のように、RDS for PostgreSQL のバージョンによっては、リードレプリカの再起動が必要になる場合があります。

  • PostgreSQL 13 以降のバージョン – 再起動は必要ありません。リードレプリカは、新しいプライマリと自動的に同期されます。ただし、場合によっては、クライアントアプリケーションがリードレプリカのドメインネームサービス (DNS) の詳細をキャッシュすることがあります。その場合は、有効期限 (TTL) 値を 30 秒未満に設定します。これにより、リードレプリカは古い IP アドレスを保持できなくなります (したがって、新しいプライマリと同期されません)。このベストプラクティスおよびその他のベストプラクティスの詳細については、「Amazon RDS の基本的な操作のガイドライン」を参照してください。

  • PostgreSQL 12 およびそれ以前のすべてのバージョン – スタンバイレプリカにフェイルオーバーした後にリードレプリカが自動的に再起動します。スタンバイ (現在のプライマリ) の IP アドレスとインスタンス名が異なるためです。再起動すると、リードレプリカが新しいプライマリと同期されます。

フェイルオーバーの詳細については、「Amazon RDS 用のマルチ AZ DB インスタンスのフェイルオーバー」を参照してください。リードレプリカがマルチ AZ 配置でどのように機能するかについての詳細は、「DB インスタンスのリードレプリカの操作」を参照してください。

リードレプリカのフェイルオーバーをサポートするため、リードレプリカをマルチ AZ DB インスタンスとして作成できます。これにより、Amazon RDS は、別のアベイラビリティーゾーン (AZ) にレプリカのスタンバイを作成できます。リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。

RDS for PostgreSQL でのカスケードリードレプリカの使用

バージョン 14.1 以降の RDS for PostgreSQL では、カスケードリードレプリカがサポートされています。カスケードリードレプリカにより、ソースの RDS for PostgreSQL DB インスタンスにオーバーヘッドを追加せずに読み取りをスケーリングできます。ソース DB インスタンスでは、WAL ログへの更新が各リードレプリカに送信されません。代わりに、カスケード層内の各リードレプリカは、その層内の次のリードレプリカに WAL ログの更新を送信します。これにより、ソース DB インスタンスへの負荷が軽減されます。

カスケードリードレプリカを使用すると、RDS for PostgreSQL DB インスタンスは、チェーン内の最初のリードレプリカに WAL データを送信します。その後、そのリードレプリカは、チェーン内の 2 番目のレプリカに WAL データを送信し、その動作が順に続いていきます。その結果、チェーン内のすべてのリードレプリカに RDS for PostgreSQL DB インスタンスの更新が送信されますが、ソース DB インスタンスでのオーバーヘッドは発生しません。

ソースの RDS for PostgreSQL DB インスタンスから、チェーン内にリードレプリカを 3 層まで作成することができます。例えば、RDS for PostgreSQL 14.1 DB インスタンス、rpg-db-main があるとします。以下の操作を行うことができます。

  • rpg-db-main で開始し、チェーン内に最初のリードレプリカ、read-replica-1 を作成します。

  • 次に、read-replica-1 で、チェーン内に次のリードレプリカ、read-replica-2 を作成します。

  • 最後に、read-replica-2 で、チェーン内に 3 番目のリードレプリカ、read-replica-3 を作成します。

rpg-db-main の層では、この 3 番目のカスケードリードレプリカに続く、別のリードレプリカを作成することはできません。一連の完全なインスタンス (RDS for PostgreSQL のソース DB インスタンスから、この層の最後のカスケードリードレプリカまで) は、最大 4 つの DB インスタンスで構成できます。

カスケードリードレプリカを設定するには、RDS for PostgreSQL で自動バックアップを有効にします。まずリードレプリカを作成し、RDS for PostgreSQL DB インスタンスで自動バックアップを有効にします。このプロセスは、他の Amazon RDS DB エンジンと同じです。詳細については、「リードレプリカの作成」を参照してください。

他のリードレプリカと同様に、カスケードの一部となっているリードレプリカを昇格できます。リードレプリカのチェーン内でリードレプリカを昇格させると、そのレプリカはチェーンから削除されます。例えば、rpg-db-main DB インスタンスのワークロードの一部を新しいインスタンスに移動するとします。この新しいインスタンスは経理部でのみ使用します。この例では、3 つのリードレプリカから成るチェーンがある仮定し、read-replica-2 を昇格させることにします。チェーンは以下のような影響を受けます。

  • 昇格する read-replica-2 は、レプリケーションチェーンから削除されます。

    • このリードレプリカは、完全な読み取り/書き込み DB インスタンスになります。

    • 昇格前と同じように、read-replica-3 へのレプリケーションを継続します。

  • rpg-db-main は、read-replica-1 へのレプリケーションを継続します。

リードレプリカの昇格についての詳細は、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。

注記

カスケードリードレプリカの場合、RDS for PostgreSQL は、レプリケーションの第 1 レベルではソース DB インスタンスごとに 15 個のリードレプリカを、レプリケーションの第 2 レベルと 第 3 レベルではソース DB インスタンスごとに 5 個のリードレプリカをサポートします。

RDS for PostgreSQL を使用したクロスリージョンカスケーディングリードレプリカの作成

RDS for PostgreSQL は、クロスリージョンカスケーディングリードレプリカをサポートします。ソース DB インスタンスからクロスリージョンレプリカを作成し、そこから同じリージョンレプリカを作成できます。ソース DB インスタンスから同じリージョンレプリカを作成し、そこからクロスリージョンレプリカを作成することもできます。

クロスリージョンレプリカを作成してから、同じリージョンレプリカを作成する

バージョン 14.1 以降 (rpg-db-main) の RDS for PostgreSQL DB インスタンス を使用して、以下を実行できます。

  1. rpg-db-main (US-EAST-1) で開始し、チェーンに最初のクロスリージョンリードレプリカ read-replica-1 (US-WEST-2) を作成します。

  2. 最初のクロスリージョン read-replica-1 (US-WEST-2) を使用して、チェーンに 2 番目のリードレプリカ read-replica-2 (US-WEST-2) を作成します。

  3. read-replica-2 を使用して、チェーンに 3 番目のリードレプリカ read-replica-3 (US-WEST-2) を作成します。

同じリージョンレプリカを作成してから、クロスリージョンレプリカを作成する

バージョン 14.1 以降 (rpg-db-main) の RDS for PostgreSQL DB インスタンス を使用して、以下を実行できます。

  1. rpg-db-main (US-EAST-1) で開始し、チェーンに最初のリードレプリカ read-replica-1 (US-EAST-1) を作成します。

  2. read-replica-1 (US-EAST-1) を使用して、チェーンに最初のクロスリージョンリードレプリカ read-replica-2 (US-WEST-2) を作成します。

  3. read-replica-2 (US-WEST-2) を使用して、チェーンに 3 番目のリードレプリカ read-replica-3 (US-WEST-2) を作成します。

クロスリージョンリードレプリカの作成に関する制限事項

  • データベースレプリカのクロスリージョンカスケーディングチェーンは、最大 2 つのリージョンにまたがることができ、最大 4 つのレベルがあります。4 つのレベルには、1 つのデータベースソースと 3 つのリードレプリカが含まれます。

カスケーディングリードレプリカを使用する利点

  • 読み取りスケーラビリティの向上 – 読み取りクエリを複数のレプリカに分散することで、カスケーディングレプリケーションは負荷均衡に役立ちます。これにより、ライターデータベースの負荷を軽減することで、特に読み取り負荷の高いアプリケーションのパフォーマンスが向上します。

  • 地理的分散 — カスケーディングレプリカは、異なる地理的場所に配置できます。これにより、プライマリデータベースから離れた場所にあるユーザーのレイテンシーが軽減され、ローカルリードレプリカが提供され、パフォーマンスとユーザーエクスペリエンスが向上します。

  • 高可用性とディザスタリカバリ — プライマリサーバーに障害が発生した場合、レプリカをプライマリに昇格させ、継続性を確保できます。カスケーディングレプリケーションは、複数のフェイルオーバーオプションを提供し、システムの全体的な耐障害性を向上させることで、これをさらに強化します。

  • 柔軟性とモジュール式の成長 — システムが成長するにつれて、プライマリデータベースの大規模な再設定を行わずに、新しいレプリカをさまざまなレベルで追加できます。このモジュール方式により、レプリケーション設定をスケーラブルかつ管理しやすい方法で拡張できます。

レプリケーションを使用する利点の詳細については、「Cloud SQL でのレプリケーションについて」を参照してください。

クロスリージョンリードレプリカを使用するためのベストプラクティス

  • レプリカを昇格させる前に、追加のレプリカを作成します。これにより、時間を節約し、ワークロードを効率的に処理できます。

RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み

「PostgreSQL でのリードレプリカの設定」で説明したとおり、RDS for PostgreSQL は PostgreSQL のネイティブストリーミングレプリケーションプロトコルを使用して、ソース DB インスタンスから WAL データを送信します。リージョン内とクロスリージョンの両方のリードレプリカにソース WAL データを送信します。バージョン 9.4 では、レプリケーションプロセスのサポートメカニズムとして、PostgreSQL に物理レプリケーションスロットが導入されました。

物理レプリケーションスロットは、WAL データがすべてのリードレプリカで消費される前に、ソース DB インスタンスによってデータが削除されることを防ぎます。各リードレプリカは、ソース DB インスタンスに独自の物理スロットを持ちます。このスロットは、レプリカが必要とする可能性のある最も古い WAL (論理シーケンス番号、LSN) を追跡します。すべてのスロットと DB との接続が指定した WAL (LSN) を超過して進行すると、その LSN は次のチェックポイントで削除候補になります。

Amazon RDS は、Amazon S3 を使用して WAL データをアーカイブします。リージョン内リードレプリカの場合は、必要に応じて、このアーカイブされたデータを使用してリードレプリカを復旧できます。その例として、何らかの理由でソース DB とリードレプリカ間の接続が中断された場合が挙げられます。

次の表は、PostgreSQL のバージョンの相違点と、RDS for PostgreSQL で使用されるリージョン内およびクロスリージョンのサポートメカニズムの相違点の概要です。

Version リージョン内 クロスリージョン
PostgreSQL 14.1 以降のバージョン

  • レプリケーションスロット

  • Amazon S3 アーカイブ

  • レプリケーションスロット
PostgreSQL 13 以前のバージョン

  • Amazon S3 アーカイブ

  • レプリケーションスロット

詳細については、「レプリケーションプロセスのモニタリングとチューニング」を参照してください。

PostgreSQL レプリケーションを制御するパラメータについて

以下のパラメータはレプリケーションプロセスに影響を与えます。また、リードレプリカがソース DB インスタンスの更新をどの程度反映するかを決定します。

max_wal_senders

max_wal_senders パラメータは、ストリーミングレプリケーションプロトコルに対して、ソース DB インスタンスが同時にサポートできる接続の最大数を指定します。RDS for PostgreSQL 13 以降のリリースでは、デフォルトは 20 です。このパラメータは、実際のリードレプリカの数よりわずかに大きな値に設定する必要があります。リードレプリカの数に対してこのパラメータの設定が低すぎる場合は、レプリケーションが停止します。

詳細については、PostgreSQL のドキュメントの「max_wal_senders」セクションを参照してください。

wal_keep_segments

wal_keep_segments パラメータは、ソース DB インスタンスが pg_wal ディレクトリで保持する先書きログ (WAL) ファイルの数を指定します。デフォルトの設定は 32 です。

wal_keep_segments がデプロイで十分な大きさの値に設定されていない場合、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。その場合、Amazon RDS でレプリケーションエラーが報告され、リードレプリカで復旧が開始されます。これは、ソース DB インスタンスのアーカイブされた WAL データを Amazon S3 で再生することによって行われます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。このプロセスを PostgreSQL ログがキャプチャしている様子については、「例: リードレプリカがレプリケーションの中断から復旧する方法」で確認できます。

注記

PostgreSQL バージョン 13 では、wal_keep_segments パラメータの名前は wal_keep_size です。このパラメータも wal_keep_segments と同じ目的を果たしますが、デフォルト値は、ファイル数ではなくメガバイト (MB) (2048 MB) です。詳細については、PostgreSQL ドキュメントの「wal_keep_segments」と「wal_keep_size」を参照してください。

max_slot_wal_keep_size

max_slot_wal_keep_size パラメータは、RDS for PostgreSQL DB インスタンスが pg_wal ディレクトリで保持する WAL データの量を制御して、スロットを提供します。このパラメータは、レプリケーションスロットを使用する構成に使用されます。このパラメータのデフォルト値は -1 です。つまり、ソース DB インスタンスに保持される WAL データの量は無制限です。レプリケーションスロットのモニタリングについては、「RDS for PostgreSQL DB インスタンスのレプリケーションスロットのモニタリング」を参照してください。

このパラメータの詳細については、PostgreSQL ドキュメントの「max_slot_wal_keep_size」を参照してください。

リードレプリカに WAL データを提供するストリームが中断した場合、PostgreSQL は復旧モードに切り替わります。リードレプリカの復元は、Amazon S3 のアーカイブ済み WAL データを使用するか、レプリケーションスロットに関連付けられている WAL データを使用して行われます。このプロセスが完了すると、PostgreSQL でストリーミングレプリケーションが再構築されます。

例: リードレプリカがレプリケーションの中断から復旧する方法

次の例では、リードレプリカの復旧プロセスを示すログの詳細を示します。この例は、同じ AWS リージョンで PostgreSQL バージョン 12.9 をソース DB として実行している RDS for PostgreSQL DB インスタンスの例です。そのため、レプリケーションスロットは使用されません。復旧プロセスは、リージョン内リードレプリカでバージョン 14.1 より前の PostgreSQL を実行している他の RDS for PostgreSQL DB インスタンスでも同じです。

リードレプリカがソース DB インスタンスとの接続を失った場合、Amazon RDS は問題を FATAL: could not receive data from WAL stream メッセージとして ERROR: requested WAL segment ... has already been removed とともにログに記録します。太字の行は、アーカイブされた WAL ファイルを再生することで Amazon RDS によりレプリカが復旧されたことを示しています。

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Amazon RDS がレプリカで遅延を解消するのに十分な、アーカイブされた WAL データを再生すると、リードレプリカへのストリーミングが再開されます。ストリーミングが再開されると、Amazon RDS によって次のようなエントリがログファイルに書き込まれます。

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

共有メモリを制御するパラメータの設定

設定したパラメータによって、トランザクション ID、ロック、準備済みトランザクションを追跡するための共有メモリのサイズが決まります。スタンバイインスタンスの共有メモリ構造は、プライマリインスタンスの共有メモリ構造と同じかそれ以上でなければなりません。これにより、リカバリ中に前者の共有メモリが不足することがなくなります。レプリカのパラメータ値がプライマリのパラメータ値よりも小さい場合、Amazon RDS はレプリカのパラメータを自動的に調整し、エンジンを再起動します。

影響を受けるパラメータは以下のとおりです。

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

メモリ不足が原因でレプリカが RDS で再起動されるのを防ぐため、パラメータの変更を各レプリカにローリング再起動として適用することをお勧めします。パラメータ設定時には、次のルールを適用する必要があります。

  • パラメータ値を増やす:

    • 必ず最初にすべてのリードレプリカのパラメータ値を増やし、すべてのレプリカのローリングリブートを実行する必要があります。次に、パラメータの変更をプライマリインスタンスに適用し、再起動します。

  • パラメータ値を減らす:

    • まず、プライマリインスタンスのパラメータ値を減らし、再起動する必要があります。次に、パラメータの変更を関連するすべてのリードレプリカに適用し、ローリングリブートを実行します。

レプリケーションプロセスのモニタリングとチューニング

RDS for PostgreSQL DB インスタンスとリードレプリカを定期的にモニタリングすることを強くお勧めします。リードレプリカがソース DB インスタンスの変更に対応していることを確認する必要があります。Amazon RDS では、レプリケーションプロセスで中断が発生した場合に、リードレプリカを透過的に復旧できます。ただし、最善なのは、復旧の必要性を最初から避けることです。レプリケーションスロットを使用した復旧は、Amazon S3 アーカイブを使用するよりも高速ですが、復旧プロセスは読み取りパフォーマンスに影響する可能性があります。

リードレプリカが最新のソース DB インスタンスにどの程度対応しているかを判断するには、次の操作を行います。

  • ソース DB インスタンスとレプリカ間の ReplicaLag の量を確認する。レプリカ遅延は、ソース DB インスタンスに対するリードレプリカの遅延時間 (秒単位) です。このメトリクスは、次のクエリの結果を返します。

    SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";

    レプリカ遅延は、リードレプリカがソース DB インスタンスの変更をどの程度反映しているかを示します。これは、ソース DB インスタンスと特定のリードインスタンス間のレイテンシーの量です。レプリカ遅延の値が大きい場合は、ソース DB インスタンスとそのリードレプリカで使用される DB インスタンスクラスまたはストレージタイプ (またはその両方) の不一致を示している可能性があります。DB ソースインスタンスとすべてのリードレプリカの DB インスタンスクラスとストレージタイプは同じである必要があります。

    レプリカ遅延は、断続的な接続問題の結果でもあります。Amazon CloudWatch のレプリケーションのラグをモニタリングするには、Amazon RDS ReplicaLag メトリクスを表示します。ReplicaLag についての詳細および Amazon RDS のその他のメトリクスについては、「Amazon RDS の Amazon CloudWatch メトリクス」を参照してください。

  • PostgreSQL ログで、設定を調整するために使用できる情報を確認する。次の例に示すように、PostgreSQL ログでは、すべてのチェックポイントで、リサイクルされるトランザクションログファイルの数がキャプチャされます。

    2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s

    この情報を使用して、指定された期間にリサイクルされるトランザクションファイルの数を把握できます。必要に応じて、wal_keep_segments の設定を変更できます。例えば、checkpoint complete の PostgreSQL ログが 5 分間隔で 35 recycled を表示するとします。この場合、wal_keep_segments のデフォルト値 32 では、ストリーミングアクティビティのペースを維持するには不十分です。そのため、このパラメータの値を大きくする必要があります。

  • Amazon CloudWatch を使用して、レプリケーションの問題を予測できるメトリクスをモニタリングする。PostgreSQL ログを直接分析する代わりに、Amazon CloudWatch を使用することで、収集されたメトリクスを確認できます。例えば、TransactionLogsGeneration メトリクスの値を確認すると、ソース DB インスタンスによって生成されている WAL データの量を把握できます。場合によっては、DB インスタンスのワークロードによって大量の WAL データが生成されることがあります。その場合、ソース DB インスタンスとリードレプリカの DB インスタンスクラスを変更する必要があります。高いネットワークパフォーマンス (10 Gbps) のインスタンスクラスを使用すると、レプリカの遅延を低減することができます。

RDS for PostgreSQL DB インスタンスのレプリケーションスロットのモニタリング

RDS for PostgreSQL のすべてのバージョンでは、クロスリージョンのリードレプリカにレプリケーションスロットを使用します。RDS for PostgreSQL 14.1 以降のバージョンでは、リージョン内のリードレプリカにレプリケーションスロットを使用します。リージョン内のリードレプリカは、Amazon S3 を使用して WAL データをアーカイブします。つまり、DB インスタンスとリードレプリカが PostgreSQL 14.1 以降を実行している場合、レプリケーションスロットと Amazon S3 アーカイブの両方を使用してリードレプリカを復旧できます。レプリケーションスロットを使用したリードレプリカの復旧は、Amazon S3 アーカイブからの復旧よりも高速です。そのため、レプリケーションスロットおよび関連するメトリクスをモニタリングすることをお勧めします。

RDS for PostgreSQL DB インスタンスのレプリケーションスロットは、次に示すように、pg_replication_slots ビューをクエリすることで表示できます。

postgres=> SELECT * FROM pg_replication_slots;
slot_name                  | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 |        | physical  |        |          | f         | t      |      13194 |      |              | 23/D8000060 |                     | reserved   |               | f
(1 row)

wal_status/reserved の値は、max_wal_size パラメータの境界内のスロットで保持されている WAL データの量を示します。つまり、レプリケーションスロットは適切にサイズ設定されています。その他のステータス値は次のとおりです。

  • extended – スロットは max_wal_size 設定を超過しますが、WAL データは保持されます。

  • unreserved – スロットに必要な WAL データがすべて含まれていません。データの一部は次のチェックポイントで削除されます。

  • lost – 必要な WAL データの一部が削除されました。スロットは使用できません。

wal_status の unreserved および lost 状態は、max_slot_wal_keep_size が負でない場合にのみ表示されます。

pg_replication_slots ビューには、レプリケーションスロットの現在の状態が表示されます。レプリケーションスロットのパフォーマンスを評価する場合、Amazon CloudWatch を使用すると、次のメトリクスをモニタリングできます。

  • OldestReplicationSlotLag – 遅延が最も大きいスロットを一覧表示します。つまり、プライマリから最も後ろにあるスロットを一覧表示します。この遅延は、リードレプリカだけでなく、接続にも関連付けることができます。

  • TransactionLogsDiskUsage – WAL データに使用されているストレージの量を示します。リードレプリカが著しく遅れると、このメトリクスの値が大幅に増加する可能性があります。

RDS for PostgreSQL での Amazon CloudWatch とそのメトリクスの使用のについての詳細は、「Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング」を参照してください。RDS for PostgreSQL DB インスタンスでストリーミングレプリケーションをモニタリングする方法の詳細については、AWS データベースブログの「Best practices for Amazon RDS PostgreSQL replication」(Amazon RDS PostgreSQL レプリケーションのベストプラクティス) を参照してください。

RDS for PostgreSQL リードレプリカのトラブルシューティング

RDS for PostgreSQL リードレプリカに関するよくある問題のトラブルシューティングについてのアイデアをいくつか以下に紹介します。

リードレプリカの遅延の原因となるクエリを終了する

トランザクションの状態がアクティブまたはアイドルであり、データベース内で長時間実行されているトランザクションは、WAL レプリケーションプロセスへの妨害となる可能性があります。これは、レプリケーション遅延の悪化につながります。このため、PostgreSQL pg_stat_activity ビューを使用して、このようなトランザクションのランタイムを必ずモニタリングしてください。

プライマリインスタンスで次のようなクエリを実行して、長時間実行されているクエリのプロセス ID (PID) を検索します。


SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
                        
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,* 
FROM  pg_stat_activity 
WHERE state  = 'idle in transaction'
AND   xact_start is not null
ORDER BY 1 DESC;

クエリの PID を特定したら、そのクエリを終了することができます。

プライマリインスタンスで次のようなクエリを実行して、長時間実行されているクエリを終了します。

SELECT pg_terminate_backend(PID);