レプリケーションラグが大きいときにリードレプリカが再起動しないようにする方法
Aurora PostgreSQLクラスターを実行しており、単一のリードレプリカとマスターノードを使用しています。
定期的に、書き込みの負荷が非常に高く、レプリケーションラグが大きくなります。これにより、リードレプリカが再起動する可能性があり、高可用性環境では望ましくありません。これが発生すると、読み取り専用エンドポイントを介してクラスターに接続されているクライアントは、このJDBCエラーを受け取ります：org.postgresql.util.PSQLException: FATAL: the database system is starting up。さらに、AWSコンソールには、ログ全体にこれらが表示されます。
リードレプリカがマスターに大きく遅れています。 postgresを再起動します。
に続く
DBインスタンスが再起動されました
リードレプリカが数分遅れることは許容できますが、キャッチアップのためにリードレプリカが再起動することは許容できません。
これらの期間中にリードレプリカが再起動しないようにする方法はありますか？
または、書き込み負荷が高い期間中のレプリケーションラグを減らすための推奨される調整はありますか？
これは、彼らが「設計どおりに機能する」と呼ぶものだと思います。 Aurora MySQL のドキュメントに記載されています（私の強調）：
複数のAuroraレプリカを持つことのトレードオフは、基礎となるデータベースインスタンスが再起動されると、レプリカが短期間使用できなくなることです。これらの再起動は、メンテナンス操作中に発生する可能性があります、またはレプリカがマスターから大幅に遅れ始めた場合。レプリカを再起動すると、対応するデータベースインスタンスへの既存の接続が中断されます。
レプリケーションの実装は同一ではないにしても非常に類似しているため、Aurora PostgreSQLでも同じことが期待されます。
この動作の理由は、変更が書き込みインスタンスから読み取りレプリカに伝達される方法によって説明されます。REDOレコードが送信され、レプリカはそれらを適切なローカルキャッシュページに正しい順序で適用することが期待されます- - このプレゼンテーション のスライド27を参照してください。
キャッシュ更新処理は高速である必要がありますが、特にそれが能力の低いAWSインスタンスで実行されている場合は、レプリカを圧倒する可能性があります。レプリカが失効したキャッシュページと失効したキャッシュページを追跡できなくなると、ゼロから始める以外に選択肢はありません。特に再起動が比較的速く発生する可能性があることを考えると、元のソリューション設計者は、新しいキャッシュの無効化とリロードのメカニズムを開発する代わりに、既存のインスタンスの起動プロセスを使用することを選択したと思います。
言い換えると、への答えは、リードレプリカの再起動を防ぐ方法があるかどうかですは「いいえ」のようです。
については、レプリケーションラグを減らすための推奨される微調整があります。ラグはレプリカのCPUとメモリ容量に完全に依存するため（I/Oが関与しないため）、レプリカ、永続的または少なくともこれらの重い更新中。
クライアントアプリケーションコードを制御できる場合は、壊れた接続をより適切に処理するようにコードを変更し、必要に応じて再試行できます。そうでない場合は、クライアントとリードレプリカの間にプロキシ（pgpoolなど）を設定してみてください。プロアクティブに接続をテストして再構築することで、痛みがある程度緩和される可能性があります。
これらの提案のいずれも機能しない場合は、AWSサポートに連絡して、より良いアイデアがあるかどうかを確認することもできます。