# RDS for PostgreSQL での遅延レプリケーションの設定
<a name="rpg-delayed-replication"></a>

## 概要と利点
<a name="rpg-delayed-replication-overview"></a>

RDS for PostgreSQL の遅延レプリケーション機能を使用すると、プライマリデータベースから 1 つ以上のスタンバイ (リードレプリカ) サーバーへのデータ変更のレプリケーションを意図的に遅延できます。これにより、データの破損、偶発的なデータ損失、またはすべてのレプリカにすぐに伝播される可能性のある誤ったトランザクションに対する貴重な保護が提供されます。

遅延レプリケーションは、以下の RDS for PostgreSQL バージョンでサポートされています。
+ 14.19 以降の 14 バージョン
+ 15.14 以降の 15 バージョン
+ 16.10 以降の 16 バージョン
+ 17.6 以降の 17 バージョン

レプリケーションプロセスにタイムラグを導入することで、データ関連のインシデントが DB クラスター全体に影響を与える前に、それを検出して対応する機会が得られます。遅延レプリケーションの主な利点は次のとおりです。
+ 偶発的な削除、更新、その他の論理的なミスから復旧できます。
+ DB クラスター全体の破損したデータの分散に対するバッファを提供します。
+ 従来のバックアップ戦略を補完する追加の復旧ポイントオプションを提供します。
+ 組織固有のニーズとリスク許容度に基づいて遅延期間を設定できます。

## 遅延レプリケーションの有効化と設定
<a name="enabling-rpg-delayed-replication"></a>

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` パラメータは動的です。インスタンスに既にアタッチされている既存のパラメータグループを変更すると、その変更は再起動を必要とせずにすぐに有効になります。ただし、インスタンスに新しいパラメータグループを適用する場合は、変更を有効にするために再起動する必要があります。

## 遅延レプリケーションリカバリの管理
<a name="managing-rpg-delayed-replication"></a>

遅延レプリケーションは、従来のポイントインタイムリカバリ方法が不十分な場合や時間がかかりすぎる場合に特に役立ちます。

遅延レプリケーション期間中は、次の 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\_superuser ロールを理解する](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)」を参照してください。

`pg_is_wal_replay_paused()` や `pg_get_wal_replay_pause_state()` などの他の関数へのアクセスには、`rds_superuser` ロールは必要ありません。

次の復旧ターゲットパラメータを使用して、遅延レプリカが復旧する時点を正確に制御できます。これらのパラメータは静的であり、変更を適用するにはデータベースを再起動する必要があります。
+ recovery\_target
+ recovery\_target\_lsn
+ recovery\_target\_name
+ recovery\_target\_time
+ recovery\_target\_xid
+ recovery\_target\_inclusive

**重要**  
一度に指定できる復旧先パラメータは 1 つだけです。設定ファイルに複数の復旧先パラメータを設定すると、エラーが発生します。

## 計画に関する考慮事項
<a name="rpg-delayed-replication-considerations"></a>

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)」を参照してください。

## 制限を理解する
<a name="rpg-delayed-replication-limitations"></a>

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