レプリケーションプロセスのモニタリングとチューニング
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 メトリクス」を参照してください。 -
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 メトリクスのモニタリング」を参照してください。RDS for PostgreSQL DB インスタンスでストリーミングレプリケーションをモニタリングする方法の詳細については、AWS データベースブログの「Best practices for Amazon RDS PostgreSQL replication