MySQL InnoDB Cluster の日常運用と障害シナリオ (MySQL Shell 8.4)

MySQLレベル: 上級所要時間: 5 分 (確認) – 1 時間 (メンバー追加)

構築手順ではありません。すでに稼働している InnoDB Cluster (Group Replication + MySQL Router、MySQL Shell AdminAPI で構築) の日常運用と障害復旧のための、シナリオ別ランブックです。シナリオ・カードを選択してください: ヘルスチェック、メンバーの追加 (clone / incremental) と削除 (force を含む)、障害メンバーの再参加、クラスタ全体停止後の再起動 (rebootClusterFromCompleteOutage)、過半数喪失時の forceQuorumUsingPartitionOf、計画的なプライマリ切替え、Router の追加 / 再 bootstrap、クラスタ・オプション (consistency、expelTimeout、memberWeight、autoRejoinTries、exitStateAction)、メタデータの rescan()。各シナリオは診断 → セーフティネット → 実施 → 検証 → 事後対応の流れで構成されています。クラスタを新規に構築する場合は InnoDB Cluster 構築ガイドを、従来の source–replica レプリケーションについてはレプリケーション運用ガイドを、8.0 → 8.4 への移行についてはアップグレード・ガイドを参照してください。

構成: MySQL ノード 3–9 台 (single-primary) + MySQL Router

シナリオ

クラスタ状態とヘルスチェック (すべて正常か) — 読取り専用: cluster.status({extended: 1})、メンバーのロール/状態/バージョン、適用キュー、Router 一覧、エラーログを確認します。何も変更せず、停止も発生しません。判断に迷う場合やアラートが発生した場合はここから始めてください。最後のステップで適切なシナリオに案内します。
新しいメンバーを追加する (addInstance: clone / incremental) — クラスタに新しい MySQL ノードを追加したい、耐障害性を上げたい (3 → 5)、または削除したノードを戻したい場合です。クラスタは書込み可能なままですが、clone 中はドナーにディスク/ネットワーク負荷がかかり、新しいノードは再起動します。
メンバーを削除する (removeInstance、必要なら force) — ノードをクラスタから恒久的に外したい (ハードウェア返却、縮小) 場合、またはノードが失われてメタデータから削除する必要がある (force) 場合です。セカンダリの削除では停止は発生しません。プライマリを削除すると数秒間の書込み停止が発生します。
障害メンバーを再参加させる (MISSING / ERROR / OFFLINE) — メンバーが再起動した、ネットワークが切断された、またはグループから除外 (expel) された場合です。過半数は稼働しており、アプリケーションは書込み可能です。rejoinInstance により、メンバーは不足分を取り込んで復帰します。クラスタの停止は発生しません。
クラスタ全体が停止した: 再起動する (rebootClusterFromCompleteOutage) — 停電、データセンターやハイパーバイザーの障害などにより全ノードが停止し、その後起動した場合です。どのメンバーでも Group Replication が動作しておらず、アプリケーションは書き込めません (停止が継続中)。クラスタは最新のメンバーから再起動します。
過半数喪失 (NO_QUORUM): 残ったメンバーで強制的にクォーラムを構成する — メンバーの過半数が同時に失われ (例: 3 台中 2 台)、残ったメンバーが NO_QUORUM により書込みを停止した場合です (書込みはハングします)。失われたメンバーが確実に停止していることを確認できれば、残ったパーティションでクラスタを再稼働させます。誤用するとスプリットブレインが発生します。メンバー 1 台の喪失 (過半数は稼働中) はこのシナリオではありません。
計画的なプライマリ切替え (setPrimaryInstance) — メンテナンス (OS パッチ、ハードウェア)、負荷分散、DR 訓練のために、プライマリ・ロールを特定のセカンダリへ計画的に移したい場合です。書込みは数秒間待機し、実行中のトランザクションは完了まで待たれます。Router は新しいプライマリへ自動的にルーティングします。
Router を追加する、または再 bootstrap する — 新しいアプリケーション・サーバーに Router をインストールしたい、Router を再 bootstrap したい (バージョン・アップグレード、クラスタの再構築、routerErrors の警告)、または古い Router のエントリを整理したい場合です。再 bootstrap 中は、その Router を経由するアプリケーション接続が一時的に切断されます。
クラスタ・オプションを変更する (consistency、expelTimeout、memberWeight…) — フェイルオーバー時の整合性、ネットワークが不安定な際にメンバーが除外されるまでの時間、フェイルオーバーの優先度、自動再参加、エラー時のメンバーの動作を調整したい場合です。クラスタ稼働中に変更でき、再起動は不要です。consistency は新しいセッションから有効になります。
メタデータを実際のグループと同期する (rescan) — cluster.status() が、メタデータにないメンバー、またはもうグループにない古いエントリに言及している場合です (手動で START GROUP_REPLICATION を実行した、古いメンバーを削除していない、サーバーを再構築したなど)。停止は発生せず、メタデータのみが更新されます。

開始前の確認

操作対象のノードに MySQL Shell … と MySQL … がインストールされている。クラスタは InnoDB Cluster 構築ガイドまたはそれと同等の方法で AdminAPI により構築されている (メタデータが存在する)。OS の root がローカルの mysql にパスワードなしで接続できる。フォームのクラスタ名は dba.getCluster().getName() から、メンバーのアドレスは cluster.status() のトポロジ内の ip:port の行から取得してください。
… アカウントのパスワードを把握している (全ノードで同一)。MySQL Shell は接続のたびにパスワードを求め、--save-passwords=never により保存しません。
ノード同士が MySQL ポート (……:……、……) と Group Replication の通信ポートで互いに到達できる。
新しいノードに、クラスタのメンバーと同じマイナー・バージョンの MySQL … がインストールされている (clone の要件)。GTID が有効、server_id が他のノードと異なり、構築ガイドの Group Replication 設定が my.cnf にある。ファイアウォール/SELinux のポートが開いている。
Router サーバーが MySQL ポートでノードに到達できる…。また repo.mysql.com に接続できる…。
変更の承認、メンテナンス・ウィンドウ (必要な場合)、アプリケーション・チームとの連絡体制が整っている。

ガイドのフェーズ

状態: クラスタ、メンバー、Router (読取り専用) — クラスタの詳細な状態を取得して保存する · SQL でメンバーとキューを確認する · Group Replication のエラー記録を確認する · Router 経由の RW/RO ルーティングを確認する · 結果を解釈し、適切なシナリオを選ぶ
1. 診断: 新しいノードとクラスタの準備はできているか — 新しいノードのバージョンと識別情報を確認する · クラスタの状態とメンバーのバージョンを確認する
2. セーフティネット — 現在のトポロジを保存する
3. 実施: メンバーを追加する — 新しいノードを構成し、管理アカウントを作成する · 新しいノードの適格性をクラスタ側から確認する · ノードをクラスタに追加する (…)
4. 検証 — 新しいメンバーが ONLINE であることを確認する
5. 事後対応 — Router、監視、インベントリを更新する
1. 診断: メンバーを削除しても安全か — 対象メンバーの状態と残りの耐障害性を表示する
2. セーフティネット — 現在のトポロジを保存する
3. 実施: メンバーを削除する — メンバーをクラスタから削除する… (force)…
force で削除したノードが戻ってきた場合 — 戻ってきたノードで Group Replication を停止してクリーンアップする
4. 検証 — 残りのメンバーを確認する
5. 事後対応 — 奇数台、Router、監視
1. 診断: メンバーはなぜ外れたか、再参加できるか — クラスタから見た対象メンバーの状態 · 対象ノードで MySQL と Group Replication の状態を表示する · errant トランザクションの確認 (対象にあってクラスタにないもの)
2. セーフティネット — 現在の状態を保存する
3. 実施: メンバーを再参加させる — rejoinInstance でメンバーを再参加させる
4. 検証 — メンバーが ONLINE であることを確認する
5. 事後対応 — 根本原因と自動再参加
1. 診断: クラスタ全体が本当に停止しているか、最新のメンバーはどれか — 各ノードで MySQL を起動し、Group Replication の状態を表示する · Shell に最新のメンバーを確認させる (dryRun)
2. セーフティネット — 全ノードの GTID セットを保存する
3. 実施: 最新のメンバーからクラスタを開始する — クラスタを再起動する
4. 検証 — 全メンバーが ONLINE であることを確認する
5. 事後対応 — Router、アプリケーション、根本原因
1. 診断: クォーラムは本当に失われているか — 残ったノードからクラスタの状態を表示する
2. セーフティネット: 失われたメンバーを隔離する — 失われたノードが停止していることを確認する (フェンシング) · 残ったパーティションの状態を保存する
3. 実施: クォーラムを強制的に構成する — 残ったパーティションでクォーラムを構成する
4. 検証と失われたメンバーの復帰 — 書込みが可能になったことを確認する · 失われたメンバーを再参加させる (…)
5. 事後対応 — トポロジを見直す
1. 診断: 対象はプライマリになる資格があるか — メンバーの状態とバージョンを確認する
2. セーフティネット — 現在の状態を保存する
3. 実施: プライマリを変更する — プライマリ・ロールを … に移す

環境に合わせた手順プランを開く →