# Amazon RDS for PostgreSQL でのリードレプリカの使用
リードレプリカをインスタンスに追加することによって、Amazon RDS for PostgreSQL DB インスタンスの読み取りをスケーリングできます。他の Amazon RDS データベースエンジンと同様、RDS for PostgreSQL は PostgreSQL のネイティブレプリケーションメカニズムを使用して、ソース DB の更新がリードレプリカに反映されるようにします。リードレプリカと Amazon RDS の概要については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
RDS for PostgreSQL でのリードレプリカの使用に関する特定の情報については、以下を参照してください。
## PostgreSQL でのリードレプリカの制限
PostgreSQL リードレプリカの制限は以下のとおりです。
+ PostgreSQL リードレプリカは読み取り専用です。リードレプリカは書き込み可能な DB インスタンスではありませんが、リードレプリカをスタンドアロンの RDS for PostgreSQL DB インスタンスに昇格させることができます。ただし、このプロセスを元に戻すことはできません。
+ RDS for PostgreSQL DB インスタンスで、14.1 より前のバージョンの PostgreSQL が実行されている場合、別のリードレプリカからリードレプリカを作成することはできません。RDS for PostgreSQL でカスケードリードレプリカがサポートされているのは、RDS for PostgreSQL バージョン 14.1 以降のリリースのみです。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。
+ PostgreSQL リードレプリカを昇格させると、書き込み可能な DB インスタンスになります。これにより、ソース DB インスタンスからの先書きログ (WAL) ファイルの受信が停止し、読み取り専用インスタンスではなくなります。RDS for PostgreSQL DB インスタンスと同様に、昇格した DB インスタンスから新しいリードレプリカを作成できます。詳細については、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
+ レプリケーションチェーン内 (一連のカスケードリードレプリカ) から PostgreSQL リードレプリカを昇格させると、既存のダウンストリームリードレプリカは、昇格したインスタンスから WAL ファイルを自動的に受信し続けます。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。
+ ソース 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 インスタンスを特定の時点に復元する](USER_PIT.md)を参照してください。
+ PostgreSQL バージョン 12 以前のリードレプリカは、60～90 日間のメンテナンスウィンドウ中に自動的に再起動し、パスワードのローテーションを適用します。スケジュールされた再起動前にレプリカからソースへの接続が切断された場合も、再起動してレプリケーションを再開します。PostgreSQL バージョン 13 以降では、パスワードのローテーションプロセス中にリードレプリカでレプリケーションの切断と再接続が短時間発生する場合があります。
# PostgreSQL でのリードレプリカの設定
RDS for PostgreSQL では、PostgreSQL ネイティブストリーミングレプリケーションを使用して、ソース DB インスタンスの読み取り専用コピーを作成します。このリードレプリカ DB インスタンスは、非同期的に作成されたソース DB インスタンスの物理レプリカです。これは、先書きログ (WAL) のデータをソース DB インスタンスからリードレプリカに送信する特別な接続によって作成されます。詳細については、PostgreSQL ドキュメントの「[Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION)」(ストリーミングレプリケーション) を参照してください。
ソース DB インスタンスでデータベースの変更が行われた場合、PostgreSQL は、非同期的に安全な接続に変更をストリーミングします。クライアントアプリケーションからソース DB インスタンスまたはリードレプリカへの通信を暗号化するには、`ssl` パラメータを `1` に設定します。詳細については、「[PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md)」を参照してください。
PostgreSQL は*レプリケーション*ロールを使用して、ストリーミングレプリケーションを実行します。このロールには特権がありますが、データの変更には使用できません。PostgreSQL ではレプリケーション処理に 1 つのプロセスを使用します。
ソース DB インスタンスのオペレーションとユーザーに影響を与えることなく、PostgreSQL リードレプリカを作成できます。Amazon RDS では、サービスに影響を与えることなく、ソース DB インスタンスとリードレプリカに必要なパラメータとアクセス許可を設定できます。ソース DB インスタンスのスナップショットが取得され、このスナップショットを使用してリードレプリカが作成されます。将来のある時点でリードレプリカを削除しても、停止は発生しません。
同一リージョン内の 1 つの ソース DB インスタンスから、最大 15 個のリードレプリカを作成できます。さらに、RDS for PostgreSQL 14.1 以降では、ソース DB インスタンスから最大 3 層のリードレプリカのチェーン (カスケード) を作成することもできます。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。いずれの場合も、ソース DB インスタンスで自動バックアップを設定する必要があります。これを行うには、DB インスタンスのバックアップ保持期間を 0 以外の値に設定します。詳細については、「[リードレプリカの作成](USER_ReadRepl.Create.md)」を参照してください。
RDS for PostgreSQL DB インスタンス用のリードレプリカをソース DB インスタンスとして同じ AWS リージョン 内に作成できます。これは、*リージョン内*レプリケーションと呼ばれます。また、ソース DB インスタンスと異なる AWS リージョン にリードレプリカを作成することもできます。これは、*クロスリージョン*レプリケーションと呼ばれます。クロスリージョンリードレプリカの設定に関する詳細は、「[別の でのリードレプリカの作成AWS リージョン](USER_ReadRepl.XRgn.md)」を参照してください。「[RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md)」で説明されているように、リージョン内およびクロスリージョンのレプリケーションプロセスをサポートするさまざまなメカニズムは、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 でサポートされている外部データラッパーを使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)」を参照してください。
## マルチ AZ 構成で RDS for PostgreSQL リードレプリカを使用する
リードレプリカは、シングル AZ DB インスタンスから、またはマルチ AZ DB インスタンスから作成できます。重要なデータの耐久性と可用性を高めるために、1 つのスタンバイレプリカを備えたマルチ AZ 配置を使用できます。*スタンバイレプリカ*は、ソース DB がフェイルオーバーした場合にワークロードを引き受けることができる専用のリードレプリカです。スタンバイレプリカを使用して読み取りトラフィックを処理することはできません。ただし、トラフィックの多いマルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置についての詳細は、「[Amazon RDS のマルチ AZ DB インスタンスデプロイ](Concepts.MultiAZSingleStandby.md)」を参照してください。
マルチ AZ 配置のソース DB インスタンスがスタンバイにフェイルオーバーすると、関連付けられているリードレプリカがスタンバイ (現在はプライマリ) をレプリケーションのソースとして使用するよう切り替わります。以下のように、RDS for PostgreSQL のバージョンによっては、リードレプリカの再起動が必要になる場合があります。
+ **PostgreSQL 13 以降のバージョン** – 再起動は必要ありません。リードレプリカは、新しいプライマリと自動的に同期されます。ただし、場合によっては、クライアントアプリケーションがリードレプリカのドメインネームサービス (DNS) の詳細をキャッシュすることがあります。その場合は、有効期限 (TTL) 値を 30 秒未満に設定します。これにより、リードレプリカは古い IP アドレスを保持できなくなります (したがって、新しいプライマリと同期されません)。このベストプラクティスおよびその他のベストプラクティスの詳細については、「[Amazon RDS の基本的な操作のガイドライン](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance)」を参照してください。
+ **PostgreSQL 12 およびそれ以前のすべてのバージョン** – スタンバイレプリカにフェイルオーバーした後にリードレプリカが自動的に再起動します。スタンバイ (現在のプライマリ) の IP アドレスとインスタンス名が異なるためです。再起動すると、リードレプリカが新しいプライマリと同期されます。
フェイルオーバーの詳細については、「[Amazon RDS 用のマルチ AZ DB インスタンスのフェイルオーバー](Concepts.MultiAZ.Failover.md)」を参照してください。リードレプリカがマルチ AZ 配置でどのように機能するかについての詳細は、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
リードレプリカのフェイルオーバーをサポートするため、リードレプリカをマルチ AZ DB インスタンスとして作成できます。これにより、Amazon RDS は、別のアベイラビリティーゾーン (AZ) にレプリカのスタンバイを作成できます。リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。
# リードレプリカの論理デコード
RDS for PostgreSQL は、PostgreSQL 16.1 を使用したスタンバイからの論理レプリケーションをサポートしています。これにより、読み取り専用スタンバイから論理デコードを作成し、プライマリ DB インスタンスの負荷を軽減できます。複数のシステム間でデータを同期する必要があるアプリケーションで可用性を高めることができます。この機能により、データウェアハウスとデータ分析のパフォーマンスが向上します。
また、特定のスタンバイのレプリケーションスロットは、そのスタンバイのプライマリへの昇格を保持します。つまり、プライマリ DB インスタンスのフェイルオーバーやスタンバイから新しいプライマリへの昇格の際にも、レプリケーションスロットは保持され、以前のスタンバイサブスクライバーには影響しません。
**リードレプリカに論理デコードを作成するには**
1. **論理レプリケーションを有効にする** – スタンバイで論理デコードを作成するには、ソース DB インスタンスとその物理レプリカで論理レプリケーションを有効にする必要があります。詳細については、「[PostgreSQL でのリードレプリカの設定](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md)」を参照してください。
+ **新しく作成された RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには** – 新しい DB カスタムパラメータグループを作成し、静的パラメータ `rds.logical_replication` を `1` に設定します。次に、この DB パラメータグループをソース DB インスタンスとその物理リードレプリカに関連付けます。詳細については、「[Amazon RDS で DB パラメータグループを DB インスタンスに関連付ける](USER_WorkingWithParamGroups.Associating.md)」を参照してください。
+ **既存の RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには** — ソース DB インスタンスとその物理リードレプリカの DB カスタムパラメータグループを変更して、静的パラメータ `rds.logical_replication` を `1` に設定します。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
**注記**
これらのパラメータの変更を適用するには、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)
```
1. **ソースデータベースにテーブルを作成する** – ソース DB インスタンスのデータベースに接続します。詳細については、「[PostgreSQL データベースエンジンを実行する DB インスタンスへの接続](USER_ConnectToPostgreSQLInstance.md)」を参照してください。
次のクエリを使用して、ソースデータベースにテーブルを作成し、値を挿入します。
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **ソーステーブルのパブリケーションを作成する** – 次のクエリを使用して、ソース 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)
```
1. **論理レプリカインスタンスからサブスクリプションを作成する** – 論理レプリカインスタンスとして別の RDS for PostgreSQL DB インスタンスを作成します。この論理レプリカインスタンスが物理リードレプリカインスタンスにアクセスできるように、VPC が正しく設定されていることを確認します。詳細については、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。ソース 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)
```
1. **論理レプリケーションスロットの状態を確認する** – ソース 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)
```
# 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 エンジンと同じです。詳細については、「[リードレプリカの作成](USER_ReadRepl.Create.md)」を参照してください。
他のリードレプリカと同様に、カスケードの一部となっているリードレプリカを昇格できます。リードレプリカのチェーン内でリードレプリカを昇格させると、そのレプリカはチェーンから削除されます。例えば、`rpg-db-main` DB インスタンスのワークロードの一部を新しいインスタンスに移動するとします。この新しいインスタンスは経理部でのみ使用します。この例では、3 つのリードレプリカから成るチェーンがある仮定し、`read-replica-2` を昇格させることにします。チェーンは以下のような影響を受けます。
+ 昇格する `read-replica-2` は、レプリケーションチェーンから削除されます。
+ このリードレプリカは、完全な読み取り/書き込み DB インスタンスになります。
+ 昇格前と同じように、`read-replica-3` へのレプリケーションを継続します。
+ `rpg-db-main` は、`read-replica-1` へのレプリケーションを継続します。
リードレプリカの昇格についての詳細は、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
**注記**
RDS for PostgreSQL は、カスケードレプリカのメジャーバージョンアップグレードをサポートしていません。メジャーバージョンアップグレードを実行する前に、カスケードレプリカを削除する必要があります。ソース DB インスタンスと第 1 レベルのレプリカのアップグレードが完了したら、再作成できます。
カスケードリードレプリカの場合、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) を作成します。
1. 最初のクロスリージョン `read-replica-1` (US-WEST-2) を使用して、チェーンに 2 番目のリードレプリカ `read-replica-2` (US-WEST-2) を作成します。
1. `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) を作成します。
1. `read-replica-1` (US-EAST-1) を使用して、チェーンに最初のクロスリージョンリードレプリカ `read-replica-2` (US-WEST-2) を作成します。
1. `read-replica-2` (US-WEST-2) を使用して、チェーンに 3 番目のリードレプリカ `read-replica-3` (US-WEST-2) を作成します。
**クロスリージョンリードレプリカの作成に関する制限事項**
+ データベースレプリカのクロスリージョンカスケーディングチェーンは、最大 2 つのリージョンにまたがることができ、最大 4 つのレベルがあります。4 つのレベルには、1 つのデータベースソースと 3 つのリードレプリカが含まれます。
**カスケーディングリードレプリカを使用する利点**
+ 読み取りスケーラビリティの向上 – 読み取りクエリを複数のレプリカに分散することで、カスケーディングレプリケーションは負荷均衡に役立ちます。これにより、ライターデータベースの負荷を軽減することで、特に読み取り負荷の高いアプリケーションのパフォーマンスが向上します。
+ 地理的分散 — カスケーディングレプリカは、異なる地理的場所に配置できます。これにより、プライマリデータベースから離れた場所にあるユーザーのレイテンシーが軽減され、ローカルリードレプリカが提供され、パフォーマンスとユーザーエクスペリエンスが向上します。
+ 高可用性とディザスタリカバリ — プライマリサーバーに障害が発生した場合、レプリカをプライマリに昇格させ、継続性を確保できます。カスケーディングレプリケーションは、複数のフェイルオーバーオプションを提供し、システムの全体的な耐障害性を向上させることで、これをさらに強化します。
+ 柔軟性とモジュール式の成長 — システムが成長するにつれて、プライマリデータベースの大規模な再設定を行わずに、新しいレプリカをさまざまなレベルで追加できます。このモジュール方式により、レプリケーション設定をスケーラブルかつ管理しやすい方法で拡張できます。
**クロスリージョンリードレプリカを使用するためのベストプラクティス**
+ レプリカを昇格させる前に、追加のレプリカを作成します。これにより、時間を節約し、ワークロードを効率的に処理できます。
# RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み
「[PostgreSQL でのリードレプリカの設定](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md)」で説明したとおり、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 で使用されるリージョン内およびクロスリージョンのサポートメカニズムの相違点の概要です。
| バージョン | リージョン内 | クロスリージョン |
| --- | --- | --- |
| PostgreSQL 14.1 以降のバージョン | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 以前のバージョン | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
詳細については、「[レプリケーションプロセスのモニタリングとチューニング](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md)」を参照してください。
## PostgreSQL レプリケーションを制御するパラメータについて
以下のパラメータはレプリケーションプロセスに影響を与えます。また、リードレプリカがソース DB インスタンスの更新をどの程度反映するかを決定します。
**max\$1wal\$1senders**
`max_wal_senders` パラメータは、ストリーミングレプリケーションプロトコルに対して、ソース DB インスタンスが同時にサポートできる接続の最大数を指定します。
デフォルト値は RDS for PostgreSQL バージョンによって異なります。
+ バージョン 13、14、15 の場合、デフォルト値は 20 です。
+ バージョン 16 以降では、デフォルト値は 35 です。
このパラメータは、実際のリードレプリカの数よりわずかに大きな値に設定する必要があります。リードレプリカの数に対してこのパラメータの設定が低すぎる場合は、レプリケーションが停止します。
詳細については、PostgreSQL のドキュメントの「[max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS)」セクションを参照してください。
`max_wal_senders` パラメータは静的であるため、変更を有効にするには、DB インスタンスを再起動する必要があります。
**wal\$1keep\$1segments**
`wal_keep_segments` パラメータは、ソース DB インスタンスが `pg_wal` ディレクトリで保持する先書きログ (WAL) ファイルの数を指定します。デフォルトの設定は 32 です。
`wal_keep_segments` がデプロイで十分な大きさの値に設定されていない場合、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。その場合、Amazon RDS でレプリケーションエラーが報告され、リードレプリカで復旧が開始されます。これは、ソース DB インスタンスのアーカイブされた WAL データを Amazon S3 で再生することによって行われます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。このプロセスを PostgreSQL ログがキャプチャしている様子については、「[例: リードレプリカがレプリケーションの中断から復旧する方法例: リードレプリカのレプリケーションの中断からの復旧](#USER_PostgreSQL.Replication.example-how-it-works)」で確認できます。
PostgreSQL バージョン 13 では、`wal_keep_segments` パラメータの名前は `wal_keep_size` です。このパラメータも `wal_keep_segments` と同じ目的を果たしますが、デフォルト値は、ファイル数ではなくメガバイト (MB) (2048 MB) です。詳細については、PostgreSQL ドキュメントの「[wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS)」と「[wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE)」を参照してください。
**max\$1slot\$1wal\$1keep\$1size**
`max_slot_wal_keep_size` パラメータは、RDS for PostgreSQL DB インスタンスが `pg_wal` ディレクトリで保持する WAL データの量を制御して、スロットを提供します。このパラメータは、レプリケーションスロットを使用する構成に使用されます。このパラメータのデフォルト値は `-1` です。つまり、ソース DB インスタンスに保持される WAL データの量は無制限です。レプリケーションスロットのモニタリングについては、「[RDS for PostgreSQL DB インスタンスのレプリケーションスロットのモニタリング](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots)」を参照してください。
このパラメータの詳細については、PostgreSQL ドキュメントの「[max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-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\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
メモリ不足が原因でレプリカが 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 メトリクス](rds-metrics.md)」を参照してください。
+ **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`** – 最も長い遅延が発生しているレプリカによって消費されていないソースの先書きログ (WAL) データの量を表示します。
+ **`TransactionLogsDiskUsage`** – WAL データに使用されているストレージの量を示します。リードレプリカが著しく遅れると、このメトリクスの値が大幅に増加する可能性があります。
RDS for PostgreSQL での Amazon CloudWatch とそのメトリクスの使用のについての詳細は、「[Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。RDS for PostgreSQL DB インスタンスでストリーミングレプリケーションをモニタリングする方法の詳細については、*AWS データベースブログ*の「[Best practices for Amazon RDS PostgreSQL replication](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/)」(Amazon RDS PostgreSQL レプリケーションのベストプラクティス) を参照してください。
# RDS for PostgreSQL での遅延レプリケーションの設定
## 概要と利点
RDS for PostgreSQL の遅延レプリケーション機能を使用すると、プライマリデータベースから 1 つ以上のスタンバイ (リードレプリカ) サーバーへのデータ変更のレプリケーションを意図的に遅延できます。これにより、データの破損、偶発的なデータ損失、またはすべてのレプリカにすぐに伝播される可能性のある誤ったトランザクションに対する貴重な保護が提供されます。
遅延レプリケーションは、以下の RDS for PostgreSQL バージョンでサポートされています。
+ 14.19 以降の 14 バージョン
+ 15.14 以降の 15 バージョン
+ 16.10 以降の 16 バージョン
+ 17.6 以降の 17 バージョン
レプリケーションプロセスにタイムラグを導入することで、データ関連のインシデントが DB クラスター全体に影響を与える前に、それを検出して対応する機会が得られます。遅延レプリケーションの主な利点は次のとおりです。
+ 偶発的な削除、更新、その他の論理的なミスから復旧できます。
+ DB クラスター全体の破損したデータの分散に対するバッファを提供します。
+ 従来のバックアップ戦略を補完する追加の復旧ポイントオプションを提供します。
+ 組織固有のニーズとリスク許容度に基づいて遅延期間を設定できます。
## 遅延レプリケーションの有効化と設定
RDS for PostgreSQL リードレプリカで遅延レプリケーションを有効にするには、次の手順に従います。
**注記**
カスケードされたリードレプリカの場合は、以下で説明するのと同じ `recovery_min_apply_delay` パラメータと手順を使用します。
**遅延レプリケーションを有効にするには**
1. 新しいカスタムパラメータグループを作成するか、既存のものを変更します。詳細については、「[Amazon RDS DB インスタンスの DB パラメータグループ](USER_WorkingWithDBInstanceParamGroups.md)」を参照してください。
1. パラメータグループの `recovery_min_apply_delay` パラメータを設定します。
+ 希望する遅延の値をミリ秒単位で設定します。例えば、1 時間の遅延の場合は 3600000 です。
+ 許可される範囲: 0～86400000 ms (0～24 時間)
+ デフォルト: 0
1. パラメータグループを、遅延レプリケーション用に設定するリードレプリカインスタンスに適用します。
1. 変更を有効にするために、リードレプリカインスタンスを再起動します。
**注記**
`recovery_min_apply_delay` パラメータは動的です。インスタンスに既にアタッチされている既存のパラメータグループを変更すると、その変更は再起動を必要とせずにすぐに有効になります。ただし、インスタンスに新しいパラメータグループを適用する場合は、変更を有効にするために再起動する必要があります。
## 遅延レプリケーションリカバリの管理
遅延レプリケーションは、従来のポイントインタイムリカバリ方法が不十分な場合や時間がかかりすぎる場合に特に役立ちます。
遅延レプリケーション期間中は、次の PostgreSQL 関数を使用して復旧プロセスを管理できます。
+ `pg_wal_replay_pause()`: 遅延レプリカの復旧プロセスを一時停止するようにリクエストします。
+ `pg_wal_replay_resume()`: 以前に一時停止していた場合は、復旧プロセスを再起動します。
+ `pg_is_wal_replay_paused()`: 復旧プロセスが現在一時停止されているかどうかを確認します。
+ `pg_get_wal_replay_pause_state()`: 復旧プロセスの現在の状態を取得します (一時停止、リクエスト、一時停止なし)。
`rds_superuser` ロールを持つユーザーには、`pg_wal_replay_pause()` および `pg_wal_replay_resume()` に対する EXECUTE 権限があります。他のデータベースユーザーがこれらの関数にアクセスする必要がある場合は、`rds_superuser` ロールを付与する必要があります。`rds_superuser` ロールの詳細については、「[rds\$1superuser ロールを理解する](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)」を参照してください。
`pg_is_wal_replay_paused()` や `pg_get_wal_replay_pause_state()` などの他の関数へのアクセスには、`rds_superuser` ロールは必要ありません。
次の復旧ターゲットパラメータを使用して、遅延レプリカが復旧する時点を正確に制御できます。これらのパラメータは静的であり、変更を適用するにはデータベースを再起動する必要があります。
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**重要**
一度に指定できる復旧先パラメータは 1 つだけです。設定ファイルに複数の復旧先パラメータを設定すると、エラーが発生します。
## 計画に関する考慮事項
RDS for PostgreSQL で遅延レプリケーションを計画する場合は、次の点を考慮してください。
+ `rdsrepladmin` 認証情報の自動ローテーション中 (90 日ごとに発生)、遅延リードレプリカが一時的に `REPLICATION_ERROR` 状態になることがあります。遅延レプリカに設定された遅延を維持するのに十分な WAL ログがある場合、WAL レシーバープロセスが一時停止し、ソースに WAL が蓄積される可能性があります。ストレージがいっぱいにならないように、レプリカのレプリケーションステータスとソースのストレージ消費量をモニタリングする必要があります。
+ 遅延リードレプリカでシステムイベント (再起動や再起動など) が発生すると、設定された遅延期間が終了するまで WAL レシーバープロセスが非アクティブのままになる `REPLICATION_ERROR` 状態になります。この動作により、ソースインスタンスに WAL が蓄積され、ストレージが枯渇する可能性があります。以下の予防策を検討してください。
+ ソースインスタンスのストレージ使用率をモニタリングするように CloudWatch アラームを設定します。
+ ストレージの自動スケーリングを有効にして、予期しない WAL の増加を処理します。
+ レプリケーションスロットあたりの WAL 保持を制限するには、レプリケート元インスタンスの `max_slot_wal_keep_size` パラメータを設定します。
+ レプリケーションラグとスロットステータスを定期的にモニタリングします。
+ 遅延が長くなると、レプリカの WAL ログが増加し、より多くのストレージが消費されます。CloudWatch アラームを使用したストレージスペースのモニタリング、自動スケーリングの有効化、または必要に応じてレプリカのキャッチアップを行います。
+ 遅延リードレプリカを昇格する場合、`recovery_min_apply_delay` パラメータは受け入れられず、保留中のすべての WAL レコードがすぐに適用されます。
+ `recovery_min_apply_delay` パラメータは、カスケードレプリケーション設定の各レベルで独立しています。レプリカに遅延を設定しても、カスケードされたレプリカの遅延には追加されません。
詳細については、「[RDS for PostgreSQL リードレプリカのドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)」と「[RDS for PostgreSQL ディザスタリカバリのドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html)」を参照してください。
## 制限を理解する
Amazon RDS for PostgreSQL の遅延レプリケーション機能には、次の制限があります。
+ ブルー/グリーンデプロイでは、遅延レプリケーションを設定するときに以下の制限があります。
+ **グリーンソースインスタンス** – パラメータグループで設定されていても、`recovery_min_apply_delay parameter` は無視されます。グリーンソースインスタンスの遅延設定は有効になりません。
+ **グリーンレプリカインスタンス** – `recovery_min_apply_delay parameter` は完全にサポートされ、PostgreSQL 設定ファイルに適用されます。遅延設定は、スイッチオーバーワークフロー中に想定どおりに機能します。
+ メジャーバージョンアップグレード用の RDS ブルー/グリーンデプロイ
+ メジャーバージョンのアップグレード中、遅延したリードレプリカは自動的に終了され、ソースインスタンスが最小限のダウンタイムを確保するためにアップグレードプロセスを続行できるようになります。ソースインスタンスのアップグレードが完了したら、遅延レプリカを手動で再作成する必要があります。
+ 遅延レプリケーションは、以下の機能と互換性がありません。
+ RDS for PostgreSQL の論理的なレプリケーション
+ RDS for PostgreSQL マルチ AZ クラスター (インバウンドレプリケーションとアウトバウンドレプリケーションの両方を含む)
+ Aurora 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);
```