# Amazon Aurora PostgreSQL でのレプリケーション
以下では Amazon Aurora PostgreSQL でのレプリケーションと、論理レプリケーションのモニタリングと使用方法について説明します。
**Topics**
+ [Aurora レプリカの使用](#AuroraPostgreSQL.Replication.Replicas)
+ [Aurora レプリカの読み取り可用性の向上](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Aurora PostgreSQL レプリケーションのモニタリング](#AuroraPostgreSQL.Replication.Monitoring)
+ [Aurora での PostgreSQL 論理レプリケーションの概要](AuroraPostgreSQL.Replication.Logical.md)
+ [Aurora PostgreSQL DB クラスターの論理レプリケーションの設定](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [論理レプリケーションをオフにする](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Aurora PostgreSQL 論理レプリケーションの書き込みスルーキャッシュと論理スロットのモニタリング](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [例: Aurora PostgreSQL と AWS Database Migration Service を使用した論理レプリケーション](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [論理レプリケーション接続の IAM 認証の設定](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Aurora レプリカの使用
*Aurora レプリカ*は Aurora DB クラスター内の独立したエンドポイントで、読み取りオペレーションのスケーリングと可用性向上に最適です。Aurora DB クラスターには、Aurora DB クラスターがある AWS リージョンのアベイラビリティーゾーン全体に配置された、最大 15 の Aurora レプリカを含めることができます。
DB クラスターボリュームは、DB クラスターのデータの複数のコピーから構成されます。ただし、クラスターボリューム内のデータは、DB クラスターのプライマリ書き込み DB インスタンスおよび Aurora レプリカに対して単一の論理的なボリュームとして表されます。Aurora レプリカの詳細については、「[Aurora レプリカ](Aurora.Replication.md#Aurora.Replication.Replicas)」を参照してください。
Aurora レプリカは、クラスターボリュームに対する読み取りオペレーション専用であるため、読み取りのスケーリングに適しています。書き込み DB インスタンスは、書き込みオペレーションを管理します。クラスターボリュームは、Aurora PostgreSQL DB クラスター内のすべてのインスタンス間で共有されます。したがって、各 Aurora レプリカでデータのコピーをレプリケートする追加作業は必要ありません。
Aurora PostgreSQL では、Aurora レプリカが削除されるとそのインスタンスエンドポイントは直ちに削除され、Aurora レプリカもリーダーエンドポイントから削除されます。削除中の Aurora レプリカで実行されているステートメントがある場合は、削除までに 3 分の猶予期間があります。既存のステートメントは、猶予期間中に適切に終了する場合があります。猶予期間が終了すると、Aurora レプリカはシャットダウンし、削除されます。
Aurora PostgreSQL DB クラスターでは、Aurora グローバルデータベースを使用し、異なる AWS リージョンの Aurora レプリカがサポートしています。詳細については、「[Amazon Aurora Global Database の使用](aurora-global-database.md)」を参照してください。
**注記**
読み取り可用性機能を備えた DB クラスターの Aurora レプリカを再起動するには、手動で実行する必要があります。この機能の前に作成された DB クラスターでは、ライター DB インスタンスを再起動すると、Aurora レプリカが自動的に再起動されます。自動再起動で再確立されるエントリポイントにより、DB クラスター全体での読み取り/書き込みの一貫性が保証されます。
## Aurora レプリカの読み取り可用性の向上
Aurora PostgreSQL は、ライター DB インスタンスが再起動したときや Aurora レプリカが書き込みトラフィックに追いつけなくなったときに読み取りリクエストを継続的に処理することで、DB クラスターの読み取り可用性を向上させます。
読み取り可用性機能は、Aurora PostgreSQL の次のバージョンでデフォルトで使用できます。
+ 16.1 以降のすべてのバージョン
+ バージョン 15 の 15.2 以降
+ バージョン 14 の 14.7 以降
+ バージョン 13 の 13.10 以降
+ バージョン 12 の 12.14 以降
読み取り可用性機能は、以下のバージョンの Aurora グローバルデータベースでサポートされています。
+ 16.1 以降のすべてのバージョン
+ 15.4 以降の 15 バージョン
+ 14.9 以降の 14 バージョン
+ 13.12 以降の 13 バージョン
+ 12.16 以降の 12 バージョン
この起動前にこれらのいずれかのバージョンで作成された DB クラスターの読み取り可用性機能を使用するには、DB クラスターのライターインスタンスを再起動します。
Aurora PostgreSQL DB クラスターの静的パラメーターを変更する場合、パラメーターの変更を有効にするにはライターインスタンスを再起動する必要があります。たとえば、`shared_buffers` の値を設定するときは、ライターインスタンスを再起動する必要があります。Aurora レプリカの読み取り可用性機能により、DB クラスターは可用性が向上し、ライターインスタンスの再起動時の影響が軽減されます。リーダーインスタンスは再起動せず、読み取りリクエストに応答し続けます。静的パラメーターの変更を適用するには、個々のリーダーインスタンスを再起動します。
Aurora PostgreSQL DB クラスターの Aurora レプリカは、ライターと再接続した後すぐにインメモリデータベースの状態に回復することで、ライターの再起動、フェイルオーバー、低速レプリケーション、ネットワークの問題などのレプリケーションエラーから回復できます。このアプローチにより、Aurora レプリカインスタンスは、クライアントデータベースを引き続き使用しながら、最新のストレージアップデートとの整合性を保つことができます。
レプリケーション復旧と競合する進行中のトランザクションはエラーを受け取る可能性がありますが、リーダーがライターに追いついたら、クライアントはこれらのトランザクションを再試行できます。
### Aurora レプリカのモニタリング
ライターの接続解除からのリカバリ時に Aurora レプリカをモニタリングできます。以下のメトリクスを使用して、リーダーインスタンスに関する最新情報を確認したり、処理中の読み取り専用トランザクションを追跡したりできます。
+ `aurora_replica_status` 関数は、リーダーインスタンスがまだ接続状態で最新の情報を返すように更新されています。クエリが実行された DB インスタンスに対応する行に対しては、`aurora_replica_status` の最終更新タイムスタンプは常に空となります。これは、リーダーインスタンスに最新のデータがあることを示します。
+ Aurora レプリカがライターインスタンスとの接続を切断して再接続すると、次のデータベースイベントが発生します。
`Read replica has been disconnected from the writer instance and reconnected.`
+ リカバリの競合が原因で読み取り専用クエリがキャンセルされると、データベースエラーログに以下の 1 つ以上のエラーメッセージが表示されることがあります。
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### 制限事項
読み取り可用性機能を備えた Aurora レプリカには、次の制限が適用されます。
+ レプリケーションの復旧中にライターインスタンスからデータをストリーミングできない場合、セカンダリ DB クラスターの Aurora レプリカが再起動できます。
+ Aurora レプリカは、オンラインレプリケーションリカバリが既に進行中の状態で再起動される場合は、オンラインレプリケーションリカバリをサポートしません。
+ Aurora レプリカは、DB インスタンスがトランザクション ID のラップアラウンドに近づくと再起動します。トランザクション ID 循環の詳細については、「[トランザクション ID 循環失敗の防止](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND )」を参照してください。
+ Aurora レプリカは、特定の状況でレプリケーションプロセスがブロックされたときに再起動できます。
## Aurora PostgreSQL レプリケーションのモニタリング
読み取りのスケーリングと高可用性は最短遅延時間に左右されます。Amazon CloudWatch `ReplicaLag` メトリクスをモニタリングすることにより、Aurora レプリカが Aurora PostgreSQL DB クラスターの書き込み DB インスタンスからどれくらい遅延しているかをモニタリングできます。Aurora レプリカは、書き込み DB インスタンスと同じクラスターボリュームから読み取るため、`ReplicaLag` メトリクスの意味は Aurora PostgreSQL DB クラスターの場合とは異なります。Aurora レプリカの `ReplicaLag` メトリクスは、書き込み DB インスタンスのページキャッシュと比較した場合の Aurora レプリカのページキャッシュの遅延を示します。
RDS インスタンスと CloudWatch メトリックスのモニタリングの詳細については、「[Amazon Aurora クラスターでのメトリクスのモニタリング](MonitoringAurora.md)」を参照してください。