Posted inMySQL

OrchestratorによるMySQLの高可用性（HA）運用ガイド：深夜2時のトポロジー自動可視化と安全なフェイルオーバー

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

深夜2時、PagerDutyのアラートがけたたましく鳴り響きます。CRITICAL - MySQL Master Unreachable。慌ててターミナルを開き、PrimaryノードへSSH接続を試みるも、Kernel panicによりConnection timeout。トランザクションが詰まり、バックエンドからは500エラーが大量に吐き出されます。

自動化された高可用性（HA）の仕組みが導入されていない場合、ここから冷や汗を流しながら15〜30分格闘することになります。各Replicaの遅延（Replication lag）を1台ずつ確認して最も進んでいるノードを昇格（Promote）させ、手動で接続文字列を書き換えなければなりません。しかし、Orchestratorがあれば、この切迫した事態を15秒足らずでスマートに解決できます。

MySQLにおける3つの代表的なHAアプローチ

MySQLレプリケーションクラスタのHAを構築する際、DevOpsエンジニアの間でよく検討されるのが以下の3つのアプローチです。

  • Keepalived / Corosync + VIP（仮想IP）構成：フローティングIPを利用したActive-Passive構成やMaster-Master構成を構築します。ノード間でハートビートを定期送信し、障害発生時にIPアドレスをフェイルオーバーさせます。
  • MHA（Master High Availability）：かつて業界標準だったPerl製のツールキットです。各ノードにSSH経由でアクセスしてステータスを確認し、不足しているリレーログ（Relay log）を補完した上で、最適なReplicaをMasterへと昇格させます。
  • Orchestrator：GitHub在籍時のShlomi Noach氏によって開発された、Go言語製のオープンソースツールです。独立したサービスとして動作し、標準のポート3306経由でMySQLと通信。トポロジーマップを自動構築し、Replicaノード間のコンセンサスに基づいて安全にフェイルオーバーを実行します。

メリット・デメリットの詳細比較

1. Keepalived + Virtual IP

メリット：導入が非常に手軽でリソース消費が少なく、インフラエンジニアにとっても馴染み深い方式です。

デメリット：「データベースを理解した判断」が一切できない点です。Keepalivedは単にポート3306の疎通確認やICMP Pingを行うだけです。Replicaで30分もの遅延が発生しているか、あるいはMasterがI/Oボトルネックに陥っているかなどは検知できません。最大のリスクはスプリットブレイン（Split-brain）であり、両ノードが同時に書き込みを受け付けてしまうと、データ整合性が完全に破壊されます。

2. MHA（Master High Availability）

メリット：Binlogやリレーログの差分補完機能が非常に優れており、トランザクションのデータロストを最小限に抑えられます。

デメリット：サーバー間でパスワードなしのSSH rootログイン権限が必要となり、重大なセキュリティリスクとなります。また、現在プロジェクトのメンテナンスが終了しています。Web UIが存在せず、多段レプリケーション（Intermediate Master）のクラスタ管理が極めて困難です。

3. Orchestrator

メリット：

  • SSH接続が不要で、基本的なレプリケーション権限を持つ専用のMySQLユーザーのみで動作します。
  • 直感的なWeb UIを備え、トポロジーをリアルタイムに視覚化。メンテナンス時もドラッグ＆ドロップ操作でReplicaの接続先を切り替えられます。
  • クラスタ全体を考慮した障害検知（Holistic failure detection）：局所的なネットワーク断による誤検知を防ぐため、すべてのReplicaからの切断が確認された場合にのみMasterダウンと判定します。
  • MySQL GTIDおよびPseudo-GTIDに完全対応。

デメリット：Orchestratorはトポロジーステータスの管理とノード昇格のみを担います。アプリケーションのトラフィックを新しいMasterへ向けるには、ProxySQLやConsul、またはVIP切り替えスクリプトなどとの連携が必要です。

どのような場合にOrchestratorへ移行すべきか？

1台のMasterと3台以上のRead Replicaで構成され、秒間数千クエリを処理するようなMySQLクラスタを運用している場合、Keepalivedではリスクが顕在化しやすくなります。Orchestratorは最もバランスの取れた選択肢であり、メンテナンス時のクリック1つによる手動スイッチオーバーと、スプリットブレインの心配がない安全な自動リカバリの両立を実現します。

Orchestratorの実践的な導入手順

ステップ1：Orchestrator用MySQLユーザーの作成

クラスタ内のすべてのノード（Primaryおよび全Replica）で、監視用ユーザーを作成します。

-- MasterおよびすべてのReplicaで実行
CREATE USER 'orc_client'@'192.168.1.%' IDENTIFIED BY 'MatKhauSieuKho123!';
GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orc_client'@'192.168.1.%';
GRANT SELECT ON performance_schema.* TO 'orc_client'@'192.168.1.%';
FLUSH PRIVILEGES;

ステップ2：Orchestrator用バックエンドデータベースの準備

Orchestratorはトポロジー状態を保持するために専用のデータベースを必要とします。検証環境ではSQLiteでも問題ありませんが、本番環境では独立したMySQLインスタンスを用意してください。

CREATE DATABASE IF NOT EXISTS orchestrator;
CREATE USER 'orc_server'@'127.0.0.1' IDENTIFIED BY 'BackendPassOrc456!';
GRANT ALL PRIVILEGES ON orchestrator.* TO 'orc_server'@'127.0.0.1';
FLUSH PRIVILEGES;

ステップ3：Orchestratorサービスのインストールと設定

監視サーバー（Ubuntu/Debian）でパッケージをダウンロードしてインストールします。

curl -LO https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator_3.2.6_amd64.deb
sudo dpkg -i orchestrator_3.2.6_amd64.deb

設定ファイル /etc/orchestrator.conf.json を編集し、主要なパラメータを設定します。

{
  "Debug": false,
  "EnableSyslog": true,
  "ListenAddress": ":3000",
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orc_server",
  "MySQLOrchestratorPassword": "BackendPassOrc456!",
  "MySQLTopologyUser": "orc_client",
  "MySQLTopologyPassword": "MatKhauSieuKho123!",
  "DiscoverByShowSlaveHosts": true,
  "InstancePollSeconds": 5,
  "RecoveryPeriodBlockSeconds": 300,
  "Processes": {
    "PreGracefulTakeoverProcesses": [],
    "PostMasterFailoverProcesses": [
      "/usr/local/bin/notify_failover.sh {failureType} {failedHost} {successorHost}"
    ]
  }
}

サービスを起動します。

sudo systemctl enable --now orchestrator
sudo systemctl status orchestrator

ステップ4：レプリケーションクラスタの検出

Web UI（http://<IP_ORCHESTRATOR>:3000）にアクセスします。クラスタを検出させるには、メニューの Clusters > Discover からMasterのIPを入力するか、以下のコマンドを実行します。

orchestrator -c discover -i 192.168.1.10:3306

Orchestratorは 192.168.1.10 に接続して SHOW REPLICA HOSTS を実行し、完全な階層ツリー構造のトポロジーマップをUI上に自動描画します。

ステップ5：自動フェイルオーバーの有効化と動作検証

Master障害時の自動フェイルオーバーを有効化するため、/etc/orchestrator.conf.json 内で以下の3つの設定項目を有効にします。

{
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "FailMasterPromotionIfSQLThreadNotUpToDate": true,
  "AutoMasterRecovery": true
}

新しい設定を反映します：sudo systemctl restart orchestrator

それでは、Master（192.168.1.10）のMySQLプロセスを停止して障害をシミュレートしてみましょう。

# Masterの突然のクラッシュをシミュレート
sudo systemctl stop mysql

ログからフェイルオーバーの進行状況を確認します。

sudo journalctl -u orchestrator -f

Orchestratorは以下のステップを順次実行します。

  1. Orchestratorサーバーから 192.168.1.10 への接続切断を確認。
  2. 全Replicaの状態をチェック。全配下ノードのIOスレッドが切断されていることを確認し、DeadMaster 状態と判定。
  3. 各Replicaの Executed_Gtid_Set を比較し、最も進んでいるノード（例: 192.168.1.11）を選出。
  4. 192.168.1.11 に対して昇格コマンドを実行：レプリケーションを停止し、書き込みを許可（SET GLOBAL read_only = 0）。
  5. 残りのReplicaの同期元を、新Master（192.168.1.11）へと切り替え。
  6. PostMasterFailoverProcesses フックを呼び出し、ProxySQLのルーティングやDNSレコードを更新。

この一連の処理はわずか10〜15秒ほどで完了します。深夜に担当者が起こされて手動介入することなく、システムの書き込み機能が自動復旧します。

Share:
Tags: