判定：適合するのは、レプリケーション遅延だけで合否を決めず、WALの受信・再生、計画的な昇格、アプリケーションの書き込み復旧、論理レプリケーションスロット、復旧手順まで確認できる構成です。
本番投入前に担当者ごとの確認結果を記録し、非同期レプリケーションで未到達のトランザクションが失われ得ること、レプリケーションはバックアップの代わりにならないことを合意しておく必要があります。
PostgreSQL 18の本番用主系と物理スタンバイを管理するDBAには、複製状態と昇格条件の確認が必要です。
インフラ担当者はサーバー資源、通信経路、障害時の分離を、アプリケーション担当者や責任者は接続復旧と業務再開の判断を確認してください。
PostgreSQL 18の主従レプリケーションを状態別に検収する
「接続中」と「切り替え可能」は同じ意味ではありません。送信側の状態だけで判断せず、プライマリでの送信位置、スタンバイでの受信位置と再生位置を照合します。PostgreSQLのストリーミングレプリケーション監視に関する公式説明では、送信側と受信側それぞれの監視方法が案内されています。
| 確認対象 | 参照する状態・情報 | 検収時の判断 |
|---|---|---|
| プライマリからの送信 | pg_stat_replication の送信・書き込み・フラッシュ・再生位置 |
スタンバイが接続しているかだけでなく、位置が継続して進んでいるかを確認します |
| スタンバイでの受信 | pg_stat_wal_receiver の受信状態と最新位置 |
WALの受信が停止していないか、プライマリ側の送信位置と比較します |
| スタンバイでの再生 | pg_last_wal_replay_lsn() などの管理関数 |
受信済みのWALが適用されているかを、受信位置とは分けて確認します |
| 複製スロット | pg_replication_slots の状態と保持中のWAL |
利用者、必要性、WAL保持によるディスク圧迫の監視方法を確認します |
実際の確認では、プライマリのpg_stat_replicationとスタンバイのpg_stat_wal_receiverをそれぞれ記録し、同じ確認時点の位置を見比べます。pg_last_wal_receive_lsn()は受信位置、pg_last_wal_replay_lsn()は再生位置の確認に使えます。管理関数の挙動はPostgreSQL 18の管理関数リファレンスで照合してください。
PostgreSQLの主従レプリケーション遅延が小さければ、すぐ切り替えてよいですか。
いいえ。遅延の表示だけでは、その値が受信の遅れか再生の遅れか、あるいは一時的な観測値かを判断できません。非同期構成では、プライマリで確定したトランザクションがスタンバイに届く前に障害が起きると、その変更が新しい主系に存在しない可能性があります。切り替え許容条件は、許容するデータ欠損と業務影響を含めてチームで定義します。
注意： 複製スロットがWALを保持し続けると、ディスク使用量が増える場合があります。スロットの利用者と保持状況を定期的に点検し、不要なスロットを放置しない運用にします。
基盤担当はサーバーと通信の前提を照合する
物理スタンバイを別の独占サーバーに置く場合でも、サーバーを借りただけで高可用性が成立するわけではありません。利用可能なCPU、ECCメモリー、直結NVMe、OS、保守時の接続手段を、実際に選択する製品情報と照らし合わせます。製品構成や料金の確認には、SFP Cloudの料金情報を参照し、記事の一般例をそのまま提供構成とみなさないでください。
| 検収項目 | 確認すること | 未確認のまま運用した場合の問題 |
|---|---|---|
| 資源とディスク | 主系・待機系のメモリー、NVMeの容量と用途、空き容量の監視 | WALやデータの増加により、受信・再生や通常処理に影響するおそれがあります |
| 通信経路 | 実際の経路、遅延や切断の検知、接続元のアクセス制御 | 接続不良をデータベース障害と誤認したり、不適切な接続を許したりします |
| 障害の分離 | 主系停止時に旧主系への書き込みをどう防ぐか | 複数ノードが書き込みを受け付けるスプリットブレインにつながります |
| 復旧手段 | SSHなどの接続方法、ログの確認方法、担当者と連絡経路 | 障害時に状態確認や復旧判断が遅れます |
専用のプライベートネットワーク、自動フェイルオーバー、クラスター運用が提供されると決めつけず、通信設計と昇格判断の責任範囲を個別に確認します。障害時に旧主系を隔離できるか、手動で切り替えるのか、誰が判断するのかを事前に記録してください。
DBAは計画的な昇格を演習する
PostgreSQLのフェイルオーバーは、スタンバイを昇格する操作だけでは完了しません。演習では変更を伴う操作を実施する前に、関係者、対象ノード、停止条件、記録方法を決めます。昇格機能とスタンバイ運用の前提はPostgreSQL 18のフェイルオーバー文書を基準に確認してください。
- [ ] 演習前に、プライマリとスタンバイ双方の識別情報、現在の役割、WAL位置を記録します。
- [ ] 書き込みを停止または制限する条件と、演習を中断する判断者を決めます。
- [ ] 計画した手順でスタンバイを昇格し、昇格後の役割とログを記録します。
- [ ] 新しい主系に対して、想定した書き込みが受け付けられることを確認します。
- [ ] 旧主系をそのまま再接続して書き込みさせず、データの分岐を防ぐ隔離・再参加手順を確認します。
この演習は、手動の昇格手順が機能するかを確かめるものです。自動検知や自動切り替えの動作を証明するものではありません。自動化を採用する場合は、その仕組みの判断条件とスプリットブレイン防止策を別途検証します。
アプリケーション担当は業務上の復旧を確認する
データベースのポートに接続できても、アプリケーションが正しいノードへ書き込めるとは限りません。接続プールの再接続、トランザクション失敗時の扱い、再送による二重処理の防止、旧主系への接続が残らないことを、アプリケーション側で確認します。
PostgreSQLのフェイルオーバー後、アプリケーションで何を確認しますか。
接続先の切り替え後に読み取りと書き込みの向きが想定どおりか、失敗したトランザクションの結果を安全に判定できるかを確認します。テスト用の変更を識別できる形で実行し、結果を検証したうえで戻せるようにします。データベースへの疎通だけを復旧完了の条件にせず、利用者に影響する処理まで確認してから業務再開を判断します。
下流データ担当は論理スロットを別に点検する
物理ストリーミングレプリケーションと論理レプリケーションは、同じ検収項目ではありません。CDCや論理サブスクリプションを使っていない環境は「対象外」と記録し、使っている環境では、昇格後も必要なコンシューマーが処理を継続できるかを確認します。
PostgreSQL 18で主系を切り替えた後、論理レプリケーションスロットは残りますか。
構成とスロットの同期状態によるため、切り替え後も利用できると一律には判断できません。必要なスロットがフェイルオーバーに対応する設定と状態になっているか、切り替え先のスロットが同期済みかを事前に確認します。詳細は論理レプリケーションのフェイルオーバー手順と、複製スロットのビュー項目で照合してください。通常の論理レプリケーションの役割は公式概要も参照できます。
放行条件とバックアップ復元を記録する
検収記録には、ノードごとの状態、昇格前後の役割、アプリケーション確認結果、論理スロットの適用可否、失敗時の停止・復旧手順をまとめます。各項目に担当者と判定を付け、未確認の項目が残る場合は本番放行を保留する責任者も明確にします。
- [ ] WALの送信・受信・再生状態をそれぞれ確認した。
- [ ] 非同期レプリケーションで起こり得るデータ欠損と許容範囲を合意した。
- [ ] 計画的な昇格と、旧主系を安全に隔離・再参加させる手順を演習した。
- [ ] アプリケーションの再接続、書き込み方向、トランザクション結果を確認した。
- [ ] 論理レプリケーションを使う場合、必要なスロットと下流処理の継続条件を確認した。
- [ ] バックアップをサーバー外に保存し、実際に復元できることを検証した。
主系・待機系への複製やソフトウェアRAIDは、機外バックアップと復元演習の代替にはなりません。バックアップ方式と復元上の考慮事項はPostgreSQL 18のバックアップとリストア文書に沿って確認します。ディスク冗長化を使う場合も、構成と運用はチーム側で設計し、別の保存先へのバックアップを維持してください。
ここまでの検収を踏まえると、共有型の環境ではCPUやディスク資源の共有条件、ストレージ性能の選択肢、障害時に制御できる範囲が要件に合わないことがあります。長期稼働で資源を専有したい場合は、SFP Cloudのサーバー構成と利用条件を確認し、メモリー、直結NVMe、OS、計費周期を要件に照らして比較する選択肢があります。ただし、サーバーのレンタルだけで主従トポロジー、自動切り替え、バックアップが用意されるわけではありません。複製経路、昇格判断、機外保存、復元演習までチームで設計・検証できる場合に、独占サーバーを候補に加えてください。