Galera Cluster 導入チェックポイント

Galera Cluster はマルチマスターによる高可用性と自動ノードプロビジョニングやローリングリスタートによる運用容易性も兼ね備えたMySQLの拡張ライブラリです。

MariaDB社からは「MariaDB Galera Cluster」として、Percona社からは「Percona XtraDB Cluster」という名称で提供されています。

データベース部分はMySQLなので高い互換性があり、運用途中のシステムからも条件が揃えば載せ替えることも可能です。

ただし、Galera Cluster を導入する際には通常のレプリケーションとは異なる制約事項があります。今回の記事では、導入に際して検討が必要なチェック項目をまとめてみました。
これらの制限は構成（接続パターン）によって回避可能な制約事項もありますので、要件やアプリケーションの対応に必要な作業量などに応じてご判断ください。

構成台数は奇数台かつ、最小構成台数は3台から

Galera Cluster ではノードが異常終了した時や、ネットワーク障害が発生してノード間の疎通が取れない時、スプリットブレインを防ぐために、通信可能なノード間で新たなクラスターを構築します。その際、ノード数が過半数に満たないクラスターに所属するノードは処理を受け付けなくなります。

そのため、Galera Cluster では、ノードの最小構成は3ノード以上で奇数台という制約があります。

ストレージエンジンは InnoDB、XtraDB のみ

更新データを他のノードへ伝播させる仕組みは InnoDB のトランザクションの仕組みに依存しているため、InnoDBもしくはInnoDBの改良版であるXtraDBのみとなります。
MyISAMやMEMORYエンジンも使えますが、更新データが他のノードに伝播しないため注意が必要です。

必ず各テーブルにプライマリーキーをつける

他のノードへ伝播させる更新データはROW形式のレプリケーションと同じでプライマリーキーによる行レベルの更新データの構造になっているため、テーブルにプライマリーキーがない場合、正しく動作しない、または著しくパフォーマンスが落ちる可能性が高いです。

COMMIT時にエラーチェックを行う

マルチマスターのため、別々のノードで同じテーブル、同じレコードに対して同じタイミングで更新処理が実行される場合があります。Galera Cluster の場合、先にコミットした方が適応され、後からコミットした方をエラーとしてロールバックが行われます。

こちらは更新処理を1つのノードに限定することで Galera Cluster 特有のロックの競合は発生しないため、この対応は不要となります。

外部キー制約の積極的な使用はおすすめしません

Galera Cluster の外部キー制約は最近まで不安定だったので利用する際は十分な検証の上で使用してください。

トランザクションは適切なサイズに保つ

大きすぎるトランザクションは他のノードへの伝播が遅くなる原因となります。
Galera Cluster ではノード間の遅延を防ぐためにFlow Controlという仕組みがありますが、トランザクション単位による制御なので大きすぎる1つのトランザクションでは制御することができません。

例えばバッチ処理で10万行の挿入処理が1つのトランザクションで実行されている場合、1000行ずつの小さなトランザクションに分割するような対応が必要です。

AUTO INCREMENTの値は連続した値にならない

マルチマスターのため、別々のノードで同じテーブルに挿入する場合、AUTO INCREMENTの値が衝突しにくいように、Galera Cluster ではノード数に応じて自動的にAUTO INCREMENTの間隔を決定しているため、連続した値となりません（3ノードの場合、3づつ増える）

また、複数ノードへの挿入処理が行われるとAUTO INCREMENTの値が必ずしも挿入順となりません。
そのため、挿入順としてAUTO INCREMENTの値をORDER BYするSELECT文は修正する必要があります。

こちらも更新処理を1つのノードに限定すれば挿入順は保証されます。また、設定でAUTO INCREMENTの間隔を変更することもできるので従来のと同じように連続した値を採番させることも可能です。

整合性が必要なSELECTの実行

通常のレプリケーションの場合、レプリケーション遅延を考慮して、更新データの一貫性が必要なSELECTが必要な場合、マスターへ接続して実行することで実現できます。Galera Cluster の場合は以下のように行います。

こちらも更新処理を一つのノードに限定することで、通常のレプリケーションと同様に、更新データの一貫性が必要なSELECTは更新処理を行なっているノードに接続することでも対応可能です。

ノードをまたぐロックは使用できない

LOCK TABLES や SELECT ~ FOR UPDATE を使用しても他のノードのロックを取得することはできません。

こちらは更新処理を一つのノードに限定することで、他のノードへまたがるロックは不要になり、回避することが可能な制約となります。

Galera Cluster 構成パターン

Galera Cluster では更新と参照をどのように分散させるかで大きく2つのパターンに分けられます。

更新分散/参照分散（マルチプライマリー）

参照のみ分散（シングルプライマリー）

構成パターンによる制約事項の違い

まとめ

Galera Cluster を導入する時に検討して欲しい項目をまとめてみました。
導入を検討する際に少しでも役に立てれば幸いです。