2016年12月にリリースされたMySQL 5.7の新機能のGroup Replicationですが、そのリリースノートの中でも比較対象として上がっていたGalera Cluster for MySQL。今回はその Galera ライブラリを使って Percona社が開発した Percona XtraDB Cluster によるディザスタリカバリー（DR）を実現するための検証を行いたいと思います。
Percona XtraDB Cluster とは？
国内ではまだまだ知名度が高くないPercona XtraDB Clusterですが、以下のような特徴があります。
- アクティブ・アクティブのマルチマスター構成による高可用性
- 全ノードに対してRead/Writeが可能
- ノードの追加と削除は自動で行えるため従来のレプリケーションと比べても運用が簡単
- クライアントからは通常のMySQLと同様に利用できるため導入の敷居が低い
最低構成台数は3台でそれぞれのノードが死活監視を行うため、管理用の専用ノードなどは必要ありません。
Percona XtraDB ClusterでのDR構成
Percona XtraDB Clusterでディザスタリカバリーを行うにはいくつかの構成がありますが、今回は以下の3拠点で7ノードを使う方法で検証を行います。
メリット
- フェイルオーバー、フェイルバックでダウンタイムが発生しない
- フェイルオーバー、特にフェイルバックでの作業が簡単
デメリット
- 7台構成のためコストがかかる
- 3拠点必要
- ネットワークのレイテンシを低くしないと更新処理のパフォーマンスに問題が出る
それぞれのメリット、デメリットを以下の検証を行いながら説明していきます。
Quorumについて
検証の前に、Percona XtraDB Clusterでノードの停止、またはネットワーク障害が発生した場合に作動するQuorumという機能を説明します。
もし、ノード間のネットワークが分断されて、２つのグループが独立して稼働してしまった場合、両方のグループで更新処理が行われてしまうとお互いのデータの一貫性が保てなくなります（スプリットブレイン）
Percona XtraDB ClusterではQuorumという仕組みを使ってスプリットブレインによる影響を最小限にするようにしています。
ここでは以下のように5ノード構成のPercona XtraDB Clusterを例に説明したいと思います。
ここで、ノード間のネットワークが切断されて、3ノードと2ノードのグループに分断されたとします。
この場合、ノード間で自分が所属するグループが半数より多いノード数のグループに属しているか（PRIMARYコンポーネント）、それ以外か（NON-PRIMARYコンポーネント）に分類されます。
PRIMARYコンポーネントに所属しているノードについては書き込み、読み込み共に行われますが、NON-PRIMARYコンポーネントに所属しているノードはインスタンス自体は立ち上がっていますが、書き込みも読み込みも出来ない状態になります。
参考 ： Weighted Quorum — Galera Cluster Documentation
次回はAWS上で検証します
次回は実際にAWSの3拠点（東京、シンガポール、ソウル）を利用して、Percona XtraDB Cluster のディザスタリカバリー構成でフェイルオーバー、フェイルバックの挙動を検証したいと思います。
