第267回　MySQL Group Replication 動作モードの違い

MySQL Group Replicationには、Single-Primary modeとMulti-Primary modeの2つの動作モードがあります。これらのモードは、ノード間の書き込みの可否や、データの整合性保証に大きな違いをもたらします。導入を検討する際には、これらのモードの違いを理解し、適切な選択をすることが重要です。本記事では、2つの動作モードの違いについて紹介します。

MySQL Group Replicationについては、過去の記事も参考にしてください。

第257回 MySQL Group Replicationの基礎知識

Group Replication の各モードについて

Single-Primary mode

クラスター内で1台だけが「Primary（読み書き可能⁠）⁠」として選出され、残りのメンバーは「Secondary（読み取り専用⁠）⁠」となります。Primaryがダウンすると、残ったメンバーの中から新しいPrimaryが自動選出されます。MySQLの一般的なSource/Replica構成に近く、アプリケーション側の複雑性を抑えられながら、Group Replicationの高可用性を享受できます。

group_replication_single_primary_modeのデフォルト値はONで、Single-Primary modeがGroup Replicationのデフォルトの動作モードとなっています。

Primaryの変更は、SELECT group_replication_set_as_primary('member_id')を実行することで、手動で行うことも可能です。

Multi-Primary mode

クラスター内の全メンバーが「Primary（読み書き可能⁠）⁠」として動作し、どのノードに対してもINSERT/UPDATE/DELETEなどの更新系クエリを発行できます。どのノードに接続しても書き込みができるため、アプリケーション側でWrite/Readの振り分けを意識しなくて済むというメリットがあります。

group_replication_single_primary_modeをOFFに設定することで、Multi-Primary modeを有効にできます。

各モードの変更

MySQL 8.0.13からSELECT group_replication_switch_to_single_primary_mode()およびSELECT group_replication_switch_to_multi_primary_mode()を使用して、Single-Primary modeと Multi-Primary modeを切り替えることができます。これらの関数は、クラスター全体でモードを切り替えるためのもので、クラスター内の全ノードで同じモードが適用されます。

MySQL 8.0.13以前のバージョンでは、Group replicationを一旦停止し、group_replication_single_primary_modeの値を変更してから、再度Group Replicationを開始する必要があります。

Single-Primary mode VS Multi-Primary mode

Single-Primary modeとMulti-Primary modeの主な違いは、書き込みの可否とデータの整合性に関するものです。

比較項目	Single-Primary mode	Multi-Primary mode
書き込みの可否	1台のPrimaryのみ書き込み可能	全ノードで書き込み可能
データの整合性	InnoDBの行ロックにより、更新の順序が保証される	ノード間でトランザクションの早い者勝ちの競争が発生し、コンフリクトによるロールバックが発生する可能性がある
クエリ互換性	ほぼ全てのSQLや外部キーが動作	外部キーやDDLに強い制約がある

書き込みの可否

各モードの紹介にあるように、Single Primary modeではPrimaryのみが書き込み可能で、Multi-Primary modeでは全ノードが書き込み可能です。この違いは各MySQLノードに対するメンテナンスの時に大きく影響します。

Single-Primary modeでは、各ノードの設定値の変更やMySQLの再起動を行う場合、Primaryノードのフェイルオーバーが必ず発生します。そのため、メンテナンスの際には一時的に書き込みの停止・ダウンタイムが発生してしまいます。

一方、Multi-Primary modeでは全ノードが書き込み可能なため、ノードの設定値の変更やMySQLの再起動を行う場合でも、他のノードが書き込みを受け付けることにより、メンテナンスの際のダウンタイムをゼロにすることができます。ただし、この場合でも後述するデータの整合性の問題が発生する可能性があるため、注意が必要です。

データの整合性

Single-Primary modeでは、全ての書き込みが1台のPrimaryに集約されるため、InnoDBの行ロックによって「待機」が発生し、順序正しく処理されます。一方、Multi-Primary modeでは、ノード間でトランザクションの早い者勝ちの競争が発生し、コンフリクトによるロールバックが発生する可能性があります。

Multi-Primary modeでは、各ノードでローカルにコミットしようとした瞬間に、他ノードとの整合性をチェックします。その時、他ノードのコミットと競合していると判断された場合、後に実行されたトランザクションは認証が失敗し、ロールバックされます。

時間	行の値（id=1）	ノード1（先にリクエスト）	ノード2（遅れてリクエスト）	状態
T1	`val=100`	`BEGIN;`	`BEGIN;`	両ノードでトランザクション開始
T2	`val=100`	`UPDATE t1 SET val=200 WHERE id=1;`		ノード1がローカルで更新（ロック取得）
T3	`val=100`		`UPDATE t1 SET val=300 WHERE id=1;`	ノード2もローカルで更新（ノード間ロックはないため成功する）
T4	`val=100`	COMMIT（送信）		ノード1がグループへ変更を通知
T5	`val=100`		COMMIT（送信）	ノード2がグループへ変更を通知
T6	`val=100`	［認証］成功（順序1位）	［認証］判定待ち	グループ全体で「ノード1が先」と合意
T7	`val=200`	コミット完了	［認証］失敗（Conflict）	ノード2の変更は「古い100」に基づいているため拒否される
T8	`val=200`	（正常終了）	ROLLBACK（強制）	ノード2はクライアントにエラーを返す

このため、Multi-Primary modeであっても通常時は書き込みノードを1ノードに固定することが推奨されます。

クエリ互換性

Single-Primary modeでは、ほぼ全てのSQLや外部キーが動作しますが、Multi-Primary modeでは、外部キーやDDLに強い制約があります。たとえば、Multi-Primary modeでは、CASCADE設定を持つ外部キーがあるテーブルへの操作は推奨されません。また、SELECT ... FOR UPDATEによるロックは、他ノードには伝播しません。

第251回　Group Replicationのマルチプライマリモードにおける外部キーの制限

また、Group Replicationの認証プロセスはDMLには適用されますが、DDLには適用されません。そのため、Multi-Primary modeではDDLの実行に対してはノード間での整合性が保証されないため、複数ノード書き込み状態でのDDLの実行は推奨されません。

時間	ノード1（DDL）	ノード2（DML）	状態
T1	`ALTER TABLE t1 DROP COLUMN c1;`（開始）		ノード1でテーブルロック（MDL）が発生
T2		`INSERT INTO t1 (c1) VALUES (10);`	［問題］ノード2はまだ古い構造なので成功する
T3	ALTER完了		ノード1の実行が完了する
T4	c1の更新が実行される	`ALTER`が実行される	各更新が各ノードに伝播
T5	［不整合/停止］		ノード1ではALTER完了後のため、c1への更新が失敗し、ノード1が停止する

Multi-Primary modeでDDLを実行したい場合は、後方互換性のあるDDLを実行する、単一ノード書き込み状態で実施する、または各ノードを順番にクラスターから切り離してDDLを実行するなどの対策が必要になります。

各モードの選択基準

一般的なWebアプリケーションでは、Single-Primary modeを前提として選択されることが多いです。Single-Primary modeは、データの整合性を重視し、アプリケーション側の複雑性を抑えたい場合に適しています。

Multi-Primary modeでは無停止のメンテナンスが可能なため、24時間365日稼働が求められるシステムや、大量のMySQL Clusterを管理しなければいけない場合に適しています。

まとめ

MySQL Group ReplicationのSingle-Primary modeとMulti-Primary modeは、それぞれ異なるユースケースに適しています。

導入を検討する際には、これらのモードの違いを理解し、システムの要件やアプリケーションの特性に応じて適切なモードを選択することが重要です。

第267回MySQL Group Replication 動作モードの違い