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

レプリカの破損 / 再同期が必要

レプリカ/スタンバイとプライマリの同期が壊れている。レプリケーションが停止しているか、どれだけ遅れているか、位置/GTID チェーンが壊れているかを判断し、エラーのスキップ、待機、再構築 (reseed) の中から適切な方法を選ぶ。スプリットブレインに関する警告を含む。

レプリケーションの全体的な状態は?

まずレプリケーションの健全性を確認する: 適用スレッドは動作しているか、遅延はどの程度か、エラーはあるか? また、2 つのノードが両方とも書き込みを受け付けていないこと (スプリットブレイン) も確認する。

SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set
  • レプリケーションが停止している / 失敗している
  • 動作しているが大きく遅れている (大きな遅延)
  • GTID/位置が壊れて不整合 — 再構築する
  • 両方のノードがプライマリとして書き込んでいる (スプリットブレインの疑い)

エラーは修復可能か、それとも再構築が必要か?

適用エラーを調べる。一部のエラー (重複キー、行の欠落) は単一のイベントを安全にスキップすることで解決できる。ただし、データの不整合/破損がある場合、唯一の正しい方法はレプリカの再構築。

SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error
  • 単一/少数の適用エラー (スキップ可能)
  • 修復不能な不整合 / 破損

遅延は一時的か、恒常的か?

遅延の推移を時系列で確認する。一時的な負荷の急増の後に解消する (追いつく) のか、それとも増え続けてレプリカがプライマリに追いつけないのか?

SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?
  • 一時的な負荷の急増。遅延は解消しつつある
  • 増え続けている。追いつけない

解決策: 適用エラーを慎重にスキップする

単一の適用エラー (例: 重複キー) でレプリケーションが停止し、データが実際に整合していると確信できる場合は、そのイベントをスキップしてストリームを継続できる。これは最終手段であり、やみくもなスキップは気付かないうちにデータのずれを生む。

解決策: レプリカを再構築する (reseed / rebuild)

位置/GTID チェーンが壊れている、データがずれている、または修復不能なエラーがある場合、唯一の信頼できる方法は、プライマリから取得した新しいコピーからレプリカを再構築すること。

根本原因: 一時的な負荷の急増 (遅延は解消しつつある)

レプリケーションは健全。プライマリでの一時的な書き込みの集中やネットワークの変動により遅延が生じたが、レプリカは追いつきつつある。

根本原因: レプリカがプライマリに追いつけない

適用 (apply/redo) 側が、プライマリが生成する変更の速度についていけず、遅延が増え続けている。通常は、シングルスレッドの適用、低速なレプリカのハードウェア、またはネットワークのボトルネック。

警告: スプリットブレイン (2 つのプライマリ) — データ損失のリスク

両方のノードがプライマリのロールで書き込みを受け付けている場合、競合する変更が両側に蓄積される。これは最も危険な状況であり、データ損失につながる可能性がある。書き込みを単一ノードに絞ることが最優先。

DBAtlas で開く →