Amazon Relational Database Service
ユーザーガイド (API バージョン 2014-10-31)

PostgreSQL リードレプリカの使用

通常、Amazon RDS DB インスタンス間のレプリケーションを設定するには、リードレプリカを使用します。リードレプリカの全般情報については、「MariaDB、MySQL、および PostgreSQL DB インスタンスのリードレプリカの使用」を参照してください。

このセクションでは、PostgreSQL でのリードレプリカの使用に関する特定の情報を提供します。

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

Amazon RDS PostgreSQL 9.3.5 以降では PostgreSQL ネイティブストリーミングレプリケーションを使用して、ソース (PostgreSQL 用語では "マスター") DB インスタンスの読み取り専用コピーを作成します。このリードレプリカ (PostgreSQL 用語では "スタンバイ") DB インスタンスは、マスター DB インスタンスの非同期的に作成された物理レプリケーションです。これは、ソース DB インスタンスとリードレプリカ間で先書きログ (WAL) データを送信する特別な接続によって作成されます。この接続では、PostgreSQL により、データベースに変更が発生したときにその変更が非同期的にストリーミングされます。

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

DB インスタンスがソース DB インスタンスとして機能するには、バックアップ保持期間を 0 以外の値に設定することにより、ソース DB インスタンスで自動バックアップを有効にする必要があります。

PostgreSQL リードレプリカを作成する際に、マスター DB インスタンスを停止する必要はありません。Amazon RDS は、サービスを中断することなく、ソース DB インスタンスとリードレプリカに必要なパラメーターおよびアクセス権限を設定します。ソース DB インスタンスのスナップショットが作成され、このスナップショットがリードレプリカになります。リードレプリカの削除時にも停止は発生しません。

1 つのソース DB インスタンスから最大 5 つのリードレプリカを作成できます。レプリケーションを効率的に実行するには、各リードレプリカに、ソース DB インスタンスと同程度の計算およびストレージリソースが必要です。ソース DB インスタンスを拡張した場合、リードレプリカも拡張する必要があります。

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

PostgreSQL DB インスタンスは、ソースとリードレプリカの両方のインスタンスについて、ssl パラメータを 1 に設定することで暗号化できる安全な接続を使用します。

リードレプリカは、シングル AZ DB インスタンス配置からもマルチ AZ DB インスタンスは一からも作成できます。重要なデータの耐久性と可用性を高めるにはマルチ AZ 配置を使用しますが、読み取り専用クエリを処理するためにマルチ AZ セカンダリを使用することはできません。代わりに、トラフィックの多い マルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置のソースインスタンスがセカンダリにフェイルオーバーすると、関連付けられたすべてのリードレプリカが、セカンダリ (今はプライマリ) をレプリケーションソースとして使用するように、自動的に切り替わります。詳細については、「高可用性 (マルチ AZ) 」を参照してください。

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

リモートサーバーからデータにアクセスするために postgres_fdw 拡張機能を使用する場合、リードレプリカからもリモートサーバーへのアクセスが可能になります。postgres_fdw の使用の詳細については、「postgres_fdw 拡張を使用した外部データへのアクセス」を参照してください。

PostgreSQL リードレプリカのモニタリング

PostgreSQL リードレプリカの場合、Amazon RDS の ReplicaLag メトリクスを表示することで、Amazon CloudWatch でのレプリケーション遅延をモニタリングできます。ReplicaLag メトリクスは、SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag の値を返します。

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

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

  • 各 PostgreSQL リードレプリカは読み取り専用で、書き込み可能リードレプリカにすることはできません。

  • リードレプリカからリードレプリカを作成することはできません (つまり、カスケードリードレプリカを作成することはできません)。

  • PostgreSQL リードレプリカを、新しいソース DB インスタンスに昇格させることができます。ただし、リードレプリカを自動的に新しいソース DB インスタンスにすることはできません。昇格した場合、リードレプリカは WAL 通信の受信を停止し、読み取り専用インスタンスではなくなります。昇格したリードレプリカは新しいソース DB インスタンスになるため、先に進むにはレプリケーションをセットアップする必要があります。

  • ソース DB インスタンスでユーザートランザクションが発生していない場合、PostgreSQL リードレプリカで 5 分以上のレプリケーションの遅延が報告されます。

PostgreSQL リードレプリカでのレプリケーションの中断

場合によっては、PostgreSQL ソース DB インスタンスによって、リードレプリカでレプリケーションが意図せず中断されることがあります。たとえば、次のような状況が考えられます。

  • max_wal_senders パラメータの設定が低すぎるため、リードレプリカの数に対して十分なデータを提供できない場合。この状況では、レプリケーションが停止します。

  • データをリードレプリカに提供するために保持する WAL ファイルの数は、PostgreSQL パラメータ、wal_keep_segments で指定します。 パラメータ値は、保持するログの数を指定します。パラメータ値の設定が低すぎると、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。この場合、Amazon RDS によりレプリケーションエラーが報告され、ソース DB インスタンスのアーカイブされた WAL ログの再生によってリードレプリカで復旧が開始されます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。詳細については、「PostgreSQL リードレプリカに関する問題のトラブルシューティング」を参照してください。

  • ソース DB インスタンスのエンドポイントが変化した場合。この状況では、PostgreSQL リードレプリカの再起動が必要になります。

リードレプリカにデータを提供する WAL ストリームが破損した場合、PostgreSQL は復旧モードに切り替えて、アーカイブされた WAL ファイルを使用してリードレプリカを保存します。このプロセスが完了すると、PostgreSQL によりストリーミングレプリケーションの再構築が試行されます。

PostgreSQL リードレプリカに関する問題のトラブルシューティング

PostgreSQL では、クロスリージョンレプリケーションにレプリケーションスロットを使用するため、同一リージョンレプリケーションの問題とクロスリージョンレプリケーションの問題のトラブルシューティングプロセスは異なります。

同一 AWS リージョン内の PostgreSQL リードレプリカ問題のトラブルシューティング

データをリードレプリカに提供するために保持する先書きログ (WAL) ファイルの数は、PostgreSQL パラメータ、wal_keep_segments で指定します。 パラメータ値は、保持するログの数を指定します。パラメータ値の設定が低すぎると、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。この場合、Amazon RDS によりレプリケーションエラーが報告され、ソース DB インスタンスのアーカイブされた WAL ログの再生によってリードレプリカで復旧が開始されます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。

アーカイブされた WAL ファイルを再生すると、リードレプリカの PostgreSQL ログから、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 ファイルをレプリカで再生します。この時点で、PostgreSQL はストリーミングを再開し、次に示すような行をログファイルに書き込みます。

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

保持する WAL ファイルの数を決めるには、ログ内のチェックポイント情報を確認します。PostgreSQL ログの各チェックポイントに次の情報が示されます。これらログステートメントの "# recycled" トランザクションログファイルを確認することで、時間範囲内にリサイクルされるトランザクションファイルの数を把握し、またこの情報を使用して wal_keep_segments パラメータを調整できます。

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

たとえば、PostgreSQL ログの "checkpoint completed" ログステートメントで、5 分間に 35 個のファイルがリサイクルされているとします。この場合、リードレプリカは 5 分間に 35 個のトランザクションファイルに依存します。ソース DB インスタンスで wal_keep_segments パラメータがデフォルト値の 32 に設定された場合、非ストリーミング状態でリードレプリカが 5 分存続できないことになります。

AWS リージョン間での PostgreSQL リードレプリカ問題のトラブルシューティング

PostgreSQL (バージョン 9.4.7 と 9.5.2 は除く) は、ソース DB インスタンスでの先書きログ (WAL) の保持に物理レプリケーションスロットを使用します。クロスリージョンリードレプリカインスタンスごとに、Amazon RDS は物理レプリケーションスロットを作成し、インスタンスに関連付けます。2 つ Amazon CloudWatch メトリクス Oldest Replication Slot LagTransaction Logs Disk Usage では、WAL データの受信時に最も長い遅延が発生しているレプリカまでの距離と、WAL データに使用されているストレージの量が表示されます。クロスリージョンリードレプリカで著しく長い遅延が発生しているときは、Transaction Logs Disk Usage の値を大幅に増やすことができます。

DB インスタンス上のワークロードにより大量の WAL データが発生する場合は、ソース DB インスタンスとリードレプリカの DB インスタンスクラスに変更する必要があります。この場合、レプリカ用に高いネットワークパフォーマンス (10 Gbps) に変更する必要があります。Amazon CloudWatch メトリクス Transaction Logs Generation は、ワークロードによる WAL データの生成率を把握するのに役立ちます。

クロスリージョンリードレプリカの状態を調べるには、以下の例のように、ソースインスタンス上の pg_replication_slots を照会できます。

postgres=# select * from pg_replication_slots; slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn _______________________________________________________________________________________________________________________________________________ rds_us_east_1_db_uzwlholddgpblksce6hgw4nkte | | physical | | | t | 12598 | | | 4E/95000060 (1 row)