LinuCレベル4 システムアーキテクト 可用性の設計 問16
可用性の設計／データレプリケーションと災害対策PostgreSQLのストリーミングレプリケーションを使って、プライマリとスタンバイによる冗長化と災害対策を設計する。説明として適切でないものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- A同期スタンバイを1台だけ指定した構成でも、そのスタンバイが停止すればプライマリは自動的に非同期へ切り替わるため、更新は止まらない
- Bスタンバイごとにレプリケーションスロットを使うと、受け取られていないWALがプライマリに保持されるため、長期間停止したスタンバイが残るとプライマリのディスクを圧迫しやすい
- Cスタンバイで参照処理も受け付ける場合、長時間の検索とWALの適用が競合し、検索が取り消されたり適用が遅れたりすることがある
- D昇格で切り替えた後に旧プライマリを戻すときは、そのまま起動せず、pg_rewindや再構築で新プライマリに合わせてからスタンバイにする
正解：A
解説
PostgreSQLの同期レプリケーションでは、synchronous_standby_namesで指定した同期スタンバイの応答が得られるまで、プライマリのコミットは待たされます。同期スタンバイが1台だけでそれが停止すると、標準の機能では非同期へ自動的には切り替わらず、更新が止まってしまいます。これを避けるには、同期スタンバイの候補を複数台指定し、そのうち所定の台数の応答で確定させる（ANYによる指定など）構成にするか、クラスタ管理ツールで設定を切り替えます。同期レプリケーションはデータ損失を防ぐ代わりに、スタンバイとの往復遅延を更新の応答時間に加えるトレードオフがあります。
選択肢ごとの解説
- A正しい（誤っている記述）。標準の機能では、同期スタンバイが応答しない間、プライマリのコミットは待たされ続けます。同期スタンバイの候補を複数台にするなどの設計が必要です。
- B誤り（正しい記述）。レプリケーションスロットはスタンバイが受信するまでWALの削除を防ぐため、停止したスタンバイのスロットが残るとWALが溜まり続けます。max_slot_wal_keep_size（PostgreSQL 13以降）で保持量に上限を設けるか、不要なスロットを削除します。
- C誤り（正しい記述）。ホットスタンバイでは、WALの適用が参照中のデータと競合すると、検索が取り消されるか、max_standby_streaming_delayなどの設定に応じて適用が遅らされます。
- D誤り（正しい記述）。旧プライマリには新プライマリへ送られていない更新が残っていることがあるため、pg_rewindで巻き戻すか作り直してから、スタンバイとして組み込みます。