Amazon RDS for PostgreSQL DB インスタンスでレプリケーション遅延を解決する方法を教えてください。
Amazon Relational Database Service (Amazon RDS) for PostgreSQL DB インスタンスでレプリケーション遅延を解決したいです。
簡単な説明
RDS for PostgreSQL のリードレプリカがプライマリインスタンスより遅れると、レプリケーションラグが発生する可能性があります。
リードレプリカは PostgreSQL のネイティブストリーミングレプリケーションを使用して同期を維持します。リードレプリカの Write Ahead Log (WAL) 受信者は、プライマリインスタンスに WAL データを要求します。プライマリインスタンスの WAL 送信者は、要求された WAL データを見つけることができない場合、セカンダリインスタンスにエラーを送信します。次に RDS for PostgreSQL は、アーカイブされた WAL データを Amazon Simple Storage Service (Amazon S3) から復元しようとします。プライマリインスタンスから WAL を削除すると、Amazon S3 はクロスリージョンレプリカリカバリをサポートしていないため、レプリケーションを再開できません。
詳細については、「Amazon RDS for PostgreSQL でのリードレプリカの使用」を参照してください。
注: 次の解決策は、ストリーミングレプリケーションの問題に対するものです。論理レプリケーションの詳細については、「Amazon RDS for PostgreSQL DB インスタンス間で論理レプリケーションを使用してテーブルを複製する方法を教えてください」を参照してください。
解決策
レプリケーションの問題を特定する
レプリケーションに関する特定の問題を特定するには、以下のメトリクスを確認してください。
- Amazon CloudWatch の ReplicaLag: このメトリクスは、リードレプリカがソース DB インスタンスより遅れている時間を秒単位で測定します。
- Amazon RDS コンソールのレプリケーション状態: レプリケーションが停止すると、このフィールドは [エラー] に変わります。
- PostgreSQL バージョン 14.1 以降でレプリケーションスロットを使用している場合は、oldestreplicationslotlag: このメトリックは、最も遅延の多いレプリカが受信していない WAL データの量をバイト単位で示します。
PostgreSQL レプリケーションを制御するパラメータを確認することもできます。
レプリケーション遅延が大きくなると、次のようなイベントメッセージが表示されることがあります。
"Streaming replication has stopped." このエラーは、プライマリインスタンスとレプリカインスタンス間のストリーミングレプリケーションが失敗したことを意味します。レプリケーションは Amazon S3 のアーカイブからの再生に切り替わります。
"Streaming replication has been terminated." このエラーは、30 日間連続してレプリケーションを停止した後に発生します。Amazon RDS は、ストレージの過剰使用を防ぐためにレプリケーションを終了します。
注: レプリケーションが停止すると、リードレプリカインスタンスは使用できますが、レプリケーションを再開することはできません。この状態から回復するには、リードレプリカを再作成します。
設定の不一致がないか確認する
リードレプリカは、プライマリインスタンスの仕様と同等かそれ以上になるように設定するのがベストプラクティスです。インスタンスクラスが小さい場合やストレージタイプが異なると、遅延が発生する可能性があります。レプリカは、プライマリと同じ書き込みワークロードを処理し、読み取りクエリも処理する必要があります。必要に応じてリードレプリカインスタンスを変更します。
プライマリインスタンスの書き込み負荷とレプリカの読み取り負荷を確認する
プライマリインスタンスでの書き込み操作により、多くの WAL ファイルが作成されます。書き込み圧力を確認するには、次の CloudWatch メトリクスと拡張モニタリング値をモニタリングします。
- TransactionLogsDiskUsage
- TransactionLogsGeneration
- WriteIOPS
- WriteThroughput
- WriteLatency
DB インスタンスクラスタイプのスループットのボトルネックを確認してください。問題を回避するには、書き込みアクティビティを複数のトランザクションに分散します。CloudWatch アラームを WriteLatency と WriteIOPS に設定して、ソースインスタンスでの大量の書き込みを識別できます。
レプリカでの読み取りアクティビティが多いと、WAL ファイルの再生が遅くなる可能性があります。高いワークロードを分析してリソースの競合をチェックするには、レプリカインスタンスで CloudWatch メトリクスまたは拡張モニタリングを使用します。必要に応じて、読み取りトラフィックを複数のリードレプリカに分散します。
テーブルロックを監視する
RDS for PostgreSQL は、プライマリインスタンスで次のコマンドを実行すると、アクセス排他ロックを処理します。 DROP TABLE、TRUNCATE、REINDEX、VACUUM FULL、および CONCURRENTLY を含まない REFRESH MATERIALIZED VIEW。詳細については、PostgreSQL のウェブサイトの「Explicit locking」(明示的ロック) を参照してください。
アクセス排他ロックは、ロックの保持期間中、他のトランザクションからそのテーブルへのアクセスを防ぎます。テーブルはトランザクションが終了するまでロックされたままになります。WAL はロックアクティビティを記録し、リードレプリカはアクティビティを再生して保持します。テーブルが アクセス排他ロック下にある時間が長いほど、レプリケーションの遅延は長くなります。
この問題を防ぐには、pg_locks と pg_stat_activity カタログテーブルを定期的にクエリするのがベストプラクティスです。
ロックを監視するには、次のコマンドを実行します。
SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid)) > 0;
出力には、ブロックされたクエリとそのブロックされたプロセスに関する情報が表示されます。
RDS で PostgreSQL のレプリケーションパラメータを確認する
レプリケーションの問題を防ぐには、RDS for PostgreSQL レプリケーションを制御するパラメータを確認します。必要に応じてパラメータ値を更新します。
レプリケーション接続の総数に合わせて、max_replication_slots を設定できます。デフォルト値はインスタンスクラスによって異なります。この値は、レプリカの総数と同じかそれを超える必要があります。
レプリカインスタンスの max_standby_streaming_delay パラメータと max_standby_archive_delay パラメータは、長時間実行される読み取りクエリを完了するのに役立ちます。レプリカで実行される読み取りクエリがソースデータを変更した場合、これらのパラメータは WAL 再生を一時停止します。値を -1 に設定すると、WAL 再生は読み取りクエリが完了するまで待機します。ただし、この一時停止により、レプリケーションの遅延が無期限に長くなり、WAL の蓄積によりソースでのストレージ消費量が増える可能性があります。
レプリケーションを安定させるため、RDS for PostgreSQL では、max_connections、max_worker_processes、max_wal_senders、max_prepared_transactions、および max_locks_per_transaction の複数のパラメータが自動的に管理されます。レプリカでは、RDS for PostgreSQL はこれらのパラメータをプライマリインスタンスの値と一致するか、それを上回るように設定します。
hot_standby_feedback パラメータを使用すると、レプリカはクエリの競合をプライマリインスタンスに報告できます。RDS for PostgreSQL では、このパラメータはデフォルトではオフになっています。パラメータを有効にすると、プライマリインスタンスのテーブルが膨張する可能性があります。次のエラーメッセージが表示されたら、hot_standby_feedback パラメータを使用してください。
"ERROR: canceling statement due to conflict with recover.Detail: User query might have needed to see row versions that must be removed"
RDS for PostgreSQL レプリケーションとクロスリージョンリードレプリカのベストプラクティスを確認する
次の理由によりレプリケーションの遅延が発生する場合もあります。
- インスタンス間のネットワーク中断
- WAL ファイルが破損した、または見つからない
- インスタンススケーリングオペレーション
- メンテナンス活動
- トランザクションのない期間
注: 詳細については、「Amazon RDS for PostgreSQL でのリードレプリカの使用」を参照してください。
これらのシナリオの詳細については、「Best practices for Amazon RDS PostgreSQL replication」(Amazon RDS PostgreSQL レプリケーションのベストプラクティス) と「Best practices for Amazon RDS for PostgreSQL cross-Region read replicas」(Amazon RDS for PostgreSQL クロスリージョンリードレプリカのベストプラクティス) を参照してください。
トランザクションを監視する
レプリケーションに影響する可能性のあるプライマリインスタンス上のアクティブなトランザクションを確認するには、次のコマンドを実行します。
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' OR state='idle in transaction';
出力には、現在実行中のトランザクションとその期間が表示されます。実行時間の長いトランザクションは、レプリケーションのパフォーマンスに影響を与える可能性があります。
問題のあるクエリを停止するには、次のコマンドを実行します。
SELECT pg_terminate_backend(PID);
注: PID を、停止したいクエリのプロセス ID 番号に置き換えてください。
関連情報
PostgreSQL のウェブサイトの Replication (レプリケーション)
Using logical replication to replicate managed Amazon RDS for PostgreSQL and Amazon Aurora to self-managed PostgreSQL (論理レプリケーションを使用して、マネージド Amazon RDS for PostgreSQL と Amazon Aurora をセルフマネージド PostgreSQL にレプリケートする)
