DBAtlas · データベース運用アトラス

レプリケーションの遅延 / 停止

スタンバイ / レプリカがプライマリから遅れている、またはレプリケーションが完全に停止している。このツリーは遅延の種類 (増加中、一定、停止) を段階的に絞り込み、適用エラー、シングルスレッドのボトルネック、リカバリの競合、破損などの根本原因にたどり着く。

遅延はどのように推移しているか?

まず状況を測定する。レプリカのストリームと遅延のメトリクスを確認する: 遅延は時間とともに増加しているか、一定の水準で止まっているか、それとも適用が完全に停止しているか? これにより、調査は 3 つの主な分岐に分かれる。

SELECT client_addr, state, write_lag, flush_lag, replay_lag,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS bytes_behind
FROM pg_stat_replication;
  • 適用が完全に停止した / エラーがある
  • 遅延が増え続けている (追いつけない)
  • 遅延は一定だが、長時間のクエリが疑われる
  • 大きく遅れている / 不整合があるように見える

適用エラーは何を示しているか?

レプリケーションが停止している場合、通常は適用中のイベントでエラーが発生している。エラーメッセージを確認する: ターゲットに行 / テーブルがないのか、主キーの競合か、接続 / ネットワークの切断か?

SHOW REPLICA STATUS\G  -- Last_Error, Last_SQL_Error, Replica_IO_Running, Replica_SQL_Running
  • 競合する行 / 存在しない行またはテーブルのエラー
  • ネットワーク / 接続が切断され、IO スレッドが停止した

なぜ追いつけないのか?

遅延が増え続けている場合、レプリカはプライマリの書き込み速度に追いつけていない。シングルスレッドの適用がボトルネックなのか、それともレプリカのディスク / IO が遅いのか? 適用ワーカーの状態と IO 待機を確認する。

SHOW REPLICA STATUS\G  -- Seconds_Behind_Source and apply thread state
SELECT * FROM performance_schema.replication_applier_status_by_worker;
  • シングルスレッドの適用 + 高い書き込み負荷
  • レプリカのディスク / IO が遅い

スタンバイで長時間のクエリが実行されているか?

読み取り専用のスタンバイで実行されている長時間のクエリは、適用 (リカバリ) をブロックすることがある。PostgreSQL ではこれによりリカバリの競合が発生する。スタンバイのアクティブなクエリと競合カウンターを確認する。

SELECT now()-query_start AS dur, pid, state, query
FROM pg_stat_activity WHERE state='active' ORDER BY query_start;
SELECT confl_snapshot, confl_lock, confl_bufferpin FROM pg_stat_database_conflicts WHERE datname=current_database();
  • はい、長時間のクエリが適用をブロックしている
  • いいえ、クエリはないが、それでも遅れている

根本原因: 適用エラー (データの競合)

レプリカが適用できないイベントで停止している: ターゲットに行がない、主キーの競合、またはテーブルがない。むやみにスキップせず、不整合の原因を修正する。

根本原因: 接続 / ネットワークの切断

受信側 (IO/receiver) スレッドがプライマリに接続できない。ネットワーク、認証、または蓄積 / 削除されたログセグメントが問題の可能性がある。

根本原因: シングルスレッド適用のボトルネック

プライマリが並列に書き込む一方で、レプリカは変更を単一の順序で適用しており、追いつけない。適用を並列化する。

根本原因: レプリカの IO ボトルネック

適用スレッドは CPU ではなくディスクを待っている。レプリカのストレージがプライマリの書き込み速度に追いつけない。

根本原因: スタンバイでのリカバリの競合

スタンバイ上の長時間の読み取り専用クエリが、プライマリからの変更の適用をブロックしている (vacuum / ロックの競合)。PostgreSQL は適用を遅らせるか、クエリをキャンセルしてこれを解消する。

根本原因: レプリカが大きく遅れている / 破損している - 再構築する

レプリカの遅れが大きすぎて回復できない、必要なログが削除されている、またはデータに不整合がある。最も安全な方法は、新しいバックアップから再構築することである。

DBAtlas で開く →