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

MySQL レプリケーションの日常運用と障害シナリオ (8.0 / 8.4)

MySQLレベル: 上級所要時間: 5 分 (確認) – 2 時間 (再構築)

構築済みの source + replica トポロジー (async / semi-sync、GTID またはバイナリログポジション) の日常運用と障害復旧の runbook です。ヘルスチェックと遅延確認、計画 switchover、failover、旧 source の再参加、replica の再構築 (clone / XtraBackup / mysqldump)、errant GTID、1062/1032 エラー、遅延 replica によるデータ復旧、replica の接続先変更、バイナリログの削除を扱います。各シナリオは 診断 → セーフティネット → 適用 → 検証 → 事後作業 の順に進みます。構築ガイドではありません。レプリケーションを初めて構築する場合は「MySQL GTID レプリケーション」、InnoDB Cluster (Group Replication) の場合は「InnoDB Cluster 運用」ガイドを開いてください。

構成: 1 source + 1..5 replica (async / semi-sync)

シナリオ

  • 状態と遅延の確認 (レプリケーションは正常か) — 読み取り専用です。IO/SQL スレッド、直近のエラー、実際の遅延、semi-sync の状態、errant GTID を確認します。何も変更せず、停止もありません。何をすべきか判断できない場合はここから始めてください。最後のステップで、出力に応じて適切なシナリオを案内します。
  • 計画 switchover (source ロールを replica に引き継ぐ) — source と replica は正常で、メンテナンス、ハードウェア交換、アップグレードのために source ロールを計画的に replica へ引き継ぎます。書き込みは数分間止まりますが、データ損失はありません。切り戻しは同じシナリオを逆方向に実行します。
  • source 喪失: 最も進んだ replica へ failover する — source がクラッシュしたか到達不能で、すぐには復帰しません (replica 側の IO スレッドが Connecting、2003/2013)。最も進んだ replica を新しい source にし、他の replica はそこへ接続します。新しい source を開放するまで書き込みはできません。async の場合、source の最後の数トランザクションが失われる可能性があります。
  • failover 後に旧 source を replica として再参加させる — failover が完了し、旧 source サーバーが復帰しました。まず書き込みを禁止してバイナリログをコピーし、errant transaction を確認します。問題がなければそのまま replica にし、あれば新しい source から再構築します。新しい source の停止はありません。
  • replica をゼロから再構築する (clone / XtraBackup / mysqldump) — replica が必要とするバイナリログが source で削除された (1236)、データが source と乖離した、1062/1032 が繰り返し発生する、または replica のディスクが失われた場合です。replica のデータをすべて source のコピーで置き換えます。source は稼働したままで、対象 replica はその間使用できません。
  • Errant GTID: source にないトランザクションが replica にある — replica に直接書き込まれた (super_read_only が無効だった間) トランザクション、または旧 source から残ったトランザクションがあります。failover 時にこれらのトランザクションが他の replica に伝播するか、1236 でレプリケーションが停止します。対処は、空のトランザクション、source への適用、または再構築です。停止はありません。
  • レプリケーション停止: 1062 Duplicate entry / 1032 Can't find record — SQL スレッドがデータエラーで停止しました (Replica_SQL_Running: No、Last_SQL_Errno 1062/1032/1146/1677…)。まず行を source 上の状態に合わせます。それができない場合は、最後の手段として 1 トランザクションだけをスキップします。影響を受けるのはこの replica だけです。遅れが生じ、ここから読むアプリケーションは古いデータを参照します。
  • 遅延 replica (SOURCE_DELAY): 設定する、または削除されたデータを復旧する — replica を意図的に N 秒遅らせておく (遅延の設定 / 解除)、または誤って削除・変更されたデータ (DROP、WHERE なしの DELETE/UPDATE) を、遅延 replica に適用される前にそこから取り戻す場合です。source は稼働したままです。
  • replica を別の source に移す (チェーン / 接続先変更) — replica を別の replica の配下 (チェーン / 中間 replica) に付け替える、または source に戻す場合です。データはコピーせず、接続先だけを変えます。移動する replica は数秒間停止します。
  • バイナリログの削除と保持期間 (ディスクが逼迫) — バイナリログがディスクを圧迫している、または保持期間を設定したい場合です。replica と PITR がまだ必要とするファイルは残したまま削除します。停止はありません。

開始前の確認

  • すべてのサーバーで MySQL …… (8.0.26 以降)… が同じマイナーバージョンであり…、gtid_mode = ON かつ enforce_gtid_consistency = ON…、バイナリログが有効…。OS の root が mysql でパスワードなしに接続できる (auth_socket または ~/.mylogin.cnf)。トポロジーは レプリケーション構築ガイド またはそれと同等の方法で構築されている。
  • ロールが入力値と一致することを確認済み: … (…) は…失われた旧 source…現在の source (read_only = 0、replica 設定なし)…、リスト内のサーバーは replica。… failover で source に昇格したサーバー: … (…)。…
  • … アカウントのパスワードが分かっている。アカウントは各サーバーの IP に対して存在する ('…'@'<ip>'、REQUIRE SSL)。各ステップはこのアカウントで他のサーバーの GTID セットなどの値を読み取り、ロール変更時にはレプリケーション接続に使います。パスワードに '、"、\ は含まれていない。
  • サーバー同士が … ポートで相互に接続できる。
  • すべてのサーバーで semi-sync プラグインが 2 つとも インストールされ ACTIVE である: rpl_semi_sync_source (semisync_source.so) と rpl_semi_sync_replica (semisync_replica.so)。ロール変更時には各サーバーで両側を有効化・無効化します。旧名の rpl_semi_sync_master / rpl_semi_sync_slave (8.0.26 より前、8.4 で非推奨) がインストールされている場合、ステップで使う rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled 変数は存在しません。先に旧プラグインを UNINSTALL PLUGIN で削除し、新しいプラグインをインストールしてください (同じサーバーに両方は読み込めません。INSTALL PLUGIN は読み取り専用サーバーでは拒否されるため、super_read_only を一時的に無効化します)。
  • 新しい source / 中間サーバーになる replica で log_bin = ON かつ log_replica_updates = ON (8.x のデフォルト)。そうでないと、そのバイナリログに source から来たトランザクションが含まれず、他の replica が接続できません。
  • ファイル転送のため、関係するサーバー間で root による SSH (鍵認証) 接続ができる…: … → ……。できない場合は、組織で承認された方法でファイルを移動してください。ファイルパスは各ステップに示されています。
  • ドナー (…) とターゲット (…) に MySQL と同じメジャーバージョンの Percona XtraBackup がインストールされ、ドナーにバックアップ用アカウント bkpuser (auth_socket) がある — XtraBackup ガイド の最初の 2 フェーズ。
  • 変更の承認と連絡体制が整っている (アプリケーションチーム、メンテナンスウィンドウ)。ロール変更時に、アプリケーションの書き込み先 (VIP、DNS、ProxySQL / HAProxy / Router) を誰がどのように切り替えるかが決まっている。

ガイドのフェーズ

  • 状態: source、replica、遅延 (読み取り専用) — source のロール、バイナリログポジション、接続中の replica を表示する · replica のスレッド状態、エラー、遅延を表示する · performance_schema で実際の遅延と適用キューを測定する · Errant GTID の確認 (source にないトランザクションが replica にあるか) · 結果を解釈して適切なシナリオを選ぶ
  • 1. 診断: switchover の準備はできているか — source と接続中の replica を確認する · 候補 replica が適格であることを確認する · すべての replica が正常であることを確認する
  • 2. セーフティネット — すべてのサーバーで現在の状態を記録する
  • 3. 適用: ロールを引き継ぐ — アプリケーションの書き込みを停止する · source の書き込みを禁止し、最終ポジションを取得する · replica が source に追いつくのを待つ · 候補を source に昇格する (promote) · 旧 source を新しい source の replica にする · 他の replica を新しい source に接続する (…) …
  • 4. 検証 — 新しい source でテスト書き込みを行う · すべてのサーバーでレプリケーションとテスト行を確認する
  • 5. 事後作業 — テスト用データベースを削除し、運用設定を更新する
  • 1. 診断: source は本当に失われたか、どの replica が最も進んでいるか — 最後にもう一度 source への接続を試す (候補 replica から) · 旧 source を隔離する (fencing) · 各 replica でリレーログ内のトランザクションが適用されるまで待つ · 最も進んだ replica を特定する · 最も進んだ replica を特定する (ポジションベース)
  • 2. セーフティネット — replica で現在の状態を記録する
  • 3. 適用: failover — 候補を source に昇格する (promote) · 他の replica を新しい source に接続する (…) · 新しい source で書き込みを開放する · アプリケーションを新しい source に向ける
  • 4. 検証 — 新しい source でテスト書き込みを行う · replica でレプリケーションとテスト行を確認する
  • 5. 事後作業 — 失われたトランザクション、バックアップ、旧 source への対応を計画する
  • 1. 診断: 旧 source はクリーンか — 旧 source の状態を表示する · errant transaction を探す (新しい source と比較) · ポジションベースでの再参加の判断
  • 2. セーフティネット — 旧 source の書き込みを直ちに禁止し、状態を記録する · errant transaction を別ファイルに抽出する
  • 3. 適用: replica として接続する — 旧 source を新しい source に接続する
  • 4. 検証 — 旧 source が replica として稼働していることを確認する
  • 5. 事後作業 — トポロジーと旧 source の今後を計画する
  • 1. 診断: errant セットは何か — errant GTID セットを計算する
  • 2. セーフティネット: errant transaction の内容を保存する — errant transaction をバイナリログからデコードして保存する
  • 3. 適用: source に空のトランザクションを注入する — errant GTID を source で空のトランザクションとして実行する
  • 3. 適用: errant transaction を source に適用する — errant transaction をファイルに抽出し、source にコピーする · トランザクションを source に適用する
  • 4. 検証 — errant セットが残っていないことを確認する
  • 5. 事後作業: 再発を防ぐ — 根本原因を特定し、replica を保護する
  • 1. 診断: どのトランザクションの、どの行か — エラーと失敗したトランザクションを表示する · 失敗したトランザクションの行をリレーログからデコードする · source と replica で行を比較する
  • 2. セーフティネット — replica の状態とテーブルの現在の状態を記録する
  • 3. 適用: replica 上の行を修正する — 修正用 SQL を準備する · バイナリログに書き込まずに修正を適用し、レプリケーションを開始する
  • 3. 適用: 失敗したトランザクションをスキップする (最後の手段) — 失敗したトランザクションだけをスキップする
  • 4. 検証 — 両側で行とテーブルのチェックサムを比較する
  • 5. 事後作業 — 根本原因を特定する
  • 1. 診断 — replica の現在の遅延設定を表示する
  • 2. セーフティネット — replica の状態を記録する
環境に合わせた手順プランを開く →