MySQL の自動フェイルオーバーと高可用性構成

サービスの可用性を維持するためには、MySQL サーバーの単一障害点をなくす設計が不可欠です。自動フェイルオーバーの仕組みを導入することで、プライマリサーバーの障害時にも短時間でサービスを復旧できるようになります。

高可用性（HA）の基本概念

高可用性とは、システムの稼働率を可能な限り高く保つための設計思想です。MySQL の文脈では、プライマリサーバーがダウンした際に、レプリカサーバーが自動的にプライマリの役割を引き継ぐ仕組みを指すことが多いです。

この一連の流れを人手を介さずに実行するのが自動フェイルオーバーであり、手動で切り替える場合と比べてダウンタイムを大幅に短縮できます。

MySQL の HA ソリューション

MySQL の高可用性を実現する方法はいくつか存在します。それぞれアーキテクチャや運用の複雑さが異なるため、サービスの要件に応じた選択が必要です。

InnoDB Cluster の構成

InnoDB Cluster は MySQL の公式 HA ソリューションとして最も推奨される選択肢です。最低 3 台のサーバーで構成され、Paxos ベースの合意プロトコルでデータの一貫性を保証します。

MySQL Router はアプリケーションとデータベースの間に配置されるプロキシです。プライマリの障害を検知すると、自動的に新しいプライマリへの接続に切り替えます。アプリケーション側は接続先として MySQL Router のアドレスを指定するだけで、バックエンドのフェイルオーバーを意識する必要がなくなります。

InnoDB Cluster のセットアップ

MySQL Shell を使って InnoDB Cluster を構築する手順を示します。まず各サーバーで Group Replication の前提条件を満たす設定が必要です。

[mysqld]
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE
log_bin = binlog
log_replica_updates = ON
binlog_format = ROW

MySQL Shell からクラスタを作成します。

-- MySQL Shell で接続
mysqlsh root@primary-host:3306

-- クラスタの作成
var cluster = dba.createCluster('myCluster');

-- セカンダリの追加
cluster.addInstance('root@secondary1:3306');
cluster.addInstance('root@secondary2:3306');

-- クラスタの状態確認
cluster.status();

cluster.status() を実行すると、各メンバーの状態やロール（PRIMARY / SECONDARY）、レプリケーションの遅延状況が確認できます。

MySQL Router の設定

MySQL Router はクラスタのメタデータを読み取り、読み書きのルーティングを自動で行います。

# Router のブートストラップ（クラスタ情報を自動取得）
mysqlrouter --bootstrap root@primary-host:3306 --directory /etc/mysqlrouter

# Router の起動
mysqlrouter -c /etc/mysqlrouter/mysqlrouter.conf

ブートストラップを実行すると、Router は読み書き用と読み取り専用の 2 つのポートを自動的に設定します。

アプリケーションは書き込みクエリをポート 6446 に、読み取りクエリをポート 6447 に送ることで、負荷分散とフェイルオーバーの両方を実現できます。

フェイルオーバーの動作

プライマリサーバーが停止すると、Group Replication の合意プロトコルによって残りのメンバーの中から新しいプライマリが自動的に選出されます。

この一連のプロセスは通常 20 秒以内に完了します。手動フェイルオーバーでは数分から数十分かかることを考えると、大幅な改善です。

スプリットブレインへの対策

分散システムにおいて最も危険な状態がスプリットブレインです。ネットワーク分断によって複数のノードが同時にプライマリを名乗ると、データの不整合が発生してしまいます。

Group Replication ではこの問題を防ぐために、クォーラム（過半数の合意）の仕組みを採用しています。3 台構成の場合、2 台以上が通信可能な状態でなければ書き込みを受け付けません。

この性質から、InnoDB Cluster は奇数台で構成するのが鉄則です。偶数台ではネットワーク分断時に過半数が確保できないケースが増え、可用性が低下します。

監視とトラブルシューティング

クラスタの健全性を維持するには、継続的な監視が欠かせません。MySQL Shell の cluster.status() は手動確認に適していますが、自動監視には performance_schema のテーブルを利用します。

-- Group Replication のメンバー状態を確認
SELECT MEMBER_ID, MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;

-- レプリケーションの遅延を確認
SELECT * FROM performance_schema.replication_group_member_stats\G

メンバーの状態が ONLINE 以外（RECOVERING, ERROR, UNREACHABLE など）になっている場合は、速やかに原因を調査する必要があります。よくある問題としては、ネットワーク遅延の増大、ディスク I/O のボトルネック、大量トランザクションによるレプリケーション遅延などが挙げられます。

HA 構成の選択指針

どの HA ソリューションを採用するかは、サービスの要件と運用チームのスキルセットによって変わります。新規構築であれば InnoDB Cluster が第一選択になりますが、既存のレプリケーション環境からの移行では Orchestrator や MHA のほうが段階的に導入しやすい場合もあります。

いずれのソリューションを選択する場合でも、定期的なフェイルオーバーテストの実施が重要です。本番環境で障害が発生してから初めてフェイルオーバーを試みるのでは遅く、平時からの演習を通じて手順と所要時間を把握しておくことが、本当の意味での高可用性を実現する鍵となります。