PostgreSQLのストリーミングレプリケーションは、障害時にもデータの整合性と継続性を確保するための仕組みとして、多くの企業で導入されています。
- 突然レプリケーションが停止し、復旧しても同期が取れない
- ネットワーク断の後にスタンバイ側が追従しない
- WALファイルが欠損し、再同期ができない
こうした事態が発生した場合、単なる設定変更では解決できない深刻な障害である可能性があります。
本記事では、ストリーミングレプリケーションに関連する障害を「ネットワーク・設定ミス・WALファイルの破損」といったカテゴリごとに明確に分類し、それぞれに最適な復旧手順を体系立てて解説しています。
誤った対処はさらなるデータ損失やダウンタイムを招きかねません。正しい知識と手順で、システムの早期復旧を目指しましょう。
障害状況の特定が難しい場合は、24時間365日対応の無料診断をご活用ください。最適な復旧プランをご提案いたします。
目次
ストリーミングレプリケーションで発生しやすい障害原因
PostgreSQLのストリーミングレプリケーションでは、障害発生時の対応を誤ると、データ不整合やシステム停止など深刻な結果を招く可能性があります。ここでは、代表的な障害原因とそのリスクについて説明します。
ネットワーク障害
プライマリとスタンバイ間の通信が途切れると、レプリケーションが停止または大幅に遅延します。AWS環境などでは、「Streaming replication has stopped」エラーが発生し、接続が自動で切断されることがあります。通信状態の継続的な監視が不可欠です。
コンフリクト(競合)
スタンバイサーバーでSELECTなどの読み取り操作が行われている間に、WALの適用処理が同じデータ領域にアクセスすると、競合が発生し、次のようなエラーで接続が終了します:
「FATAL: terminating connection due to conflict with recovery」。
設定不備
以下のような設定ミスは、レプリケーションの停止や不整合の原因となります。
- WAL関連パラメータ(wal_keep_sizeなど)の不適切な値
- レプリケーションスロットの放置
- synchronous_standby_namesの誤設定
手動操作ミス
スタンバイ側で直接データを変更するなど、本来許されない操作を行うと、即座に同期が崩れます。また、論理レプリケーションとの併用環境では、フェイルオーバー時の手順ミスも大きなリスクとなります。
ハードウェア障害

スタンバイサーバーでディスク障害や故障が発生すると、WALファイル(Write Ahead Log)が読み取れず、プライマリとの同期が途絶えます。
特にWALファイルの破損は深刻で、再構築が必要になる場合もあります。復旧には時間とコストがかかるため、初期対応の速さが鍵を握ります。
軽微な異常でも早期に診断を行うことが重要です。
デジタルデータリカバリーでは、経験豊富なエンジニアが障害の発生状況を詳細に分析し、最適な復旧方法をご提案します。初期診断とお見積りは無料で、24時間365日体制でのご相談が可能です。スタンバイサーバーの異常やWAL関連のエラーを検知した際は、被害が拡大する前に、ぜひ一度ご相談ください。
ストリーミングレプリケーション障害の復旧方法
以下では、発生しうる各障害に対して、実際に復旧を行うための具体的な手順を紹介します。使用するPostgreSQLのバージョンにより一部コマンドや動作が異なるため、事前に環境の確認も重要です。
コンフリクト解決策
スタンバイでSELECT等を行っていると、WAL適用処理と競合することがあります。以下の方法で回避や解決が可能です。
- アプリケーション側にリトライ処理を実装し、一時的な切断への耐性を持たせる
- トランザクションを短く保ち、ロック保持時間を最小化する
- postgresql.confで
max_standby_streaming_delay
を調整し、WAL適用の待機時間を制御(例:60秒に変更)
フェイルオーバー手順
プライマリが停止した場合、スタンバイを新しいプライマリとして昇格させる必要があります。適切な手順を踏むことで、データの損失や整合性の破壊を防ぎます。
- スタンバイ側で
pg_ctl promote
を実行して昇格させる - 新プライマリのpostgresql.confで
synchronous_standby_names
を空に設定 - 旧プライマリが復旧したら、
pg_rewind
を使用して差分同期を実施
レプリケーション遅延対策
遅延は業務影響や不整合を招きます。定期的な監視とパラメータのチューニングが重要です。
- ネットワークの帯域幅とレイテンシを監視・最適化
- 長時間実行されるトランザクションを避ける
wal_buffers
やmax_wal_size
を適切に調整する- 不要なレプリケーションスロットを削除・管理
pg_rewindによる差分同期
PostgreSQL 14以降では、スタンバイをソースとして差分復旧が可能です。旧プライマリを再参加させる際に有効です。
- 旧プライマリを正常停止し、クラッシュ状態でないことを確認
pg_rewind --source-pgdata=/スタンバイ --target-pgdata=/旧プライマリ
を実行recovery.conf
を再設定し、standby_mode=on
とprimary_conninfo
を記載- 同期設定を元に戻し、サーバーを再起動