MySQL Group ReplicationとはInnoDBで利用可能なレプリケーションプラグインです。複数台のMySQLサーバーをクラスタとして構築でき、従来のSource/Replica構成と比べていくつかの特徴があります。これまでの記事では外部キー制限やFlow Controlについて触れましたが、ここではGroup Replicationの基本的な仕組みや簡単な構築方法について説明します。

Group Replicationとは？

Group Replicationは複数台のMySQLサーバをクラスタとして構成し、同一の更新履歴を全ノードに届けるためのレプリケーションプラグインです。整合性を保つ仕組みや自動フェイルオーバーが可能などの特徴があります。シングルプライマリのみならずマルチプライマリモードもサポートしており、複数ノードでの同時書き込みをサポートしています。ただし、マルチプライマリでの同時書き込みは整合性の面で問題が生じる可能性があるため、明確な目的がない限り実運用ではシングルプライマリ、またはマルチプライマリで書き込みノードを1ノードに固定する方法が推奨です。

前提

Group Replicationの利用には以下の前提を満たす必要があります。

• ストレージエンジンがInnoDBであること
• Primary KeyまたはNOT NULLの一意キーがあること
• binlog_format=ROWであること
• log_replica_updates=ONであること
• gtid_mode=ONかつenforce_gtid_consistency=ONであること

Group ReplicationはInnoDBのトランザクション機構を前提としているため、ストレージエンジンはInnoDBである必要があります。また、各トランザクションのwriteset（PK/一意キー）で衝突を検出し、整合性を保証します。バイナリログやGTIDの設定は、データ一貫性や分散リカバリのために必要になります。

詳細な要件は、公式ドキュメント Group Replication Requirements から確認することができます。

従来のSource/Replica構成との違い

Source/Replica構成もMySQLクラスタの冗長化のためによく使われる方法です。Group ReplicationとSource/Replicaを比較したとき、それぞれ以下のような違いがあります。

Group Replicationは整合性チェックや自動フェイルオーバーの仕組みを備える一方、Source/Replicaにおいても構成の自由度などがメリットとして挙げられます。構成によって運用手順も大きく変わるため、どちらを選ぶかは要件や運用方針によって選択するのが適切です。

トランザクションがコミットされるまでの流れ

Group Replicationでトランザクションがコミットされるまでの流れを示します。Source/Replicaと大きく異なる点として、（⁠1）GCS、（⁠2）writesetによる認証、（⁠3）クォーラム合意の3点があります。

1. まず書き込みノードでクエリが実行されると、更新対象を一意に特定するwriteset（PK/一意キー）を抽出します。これを用いて以降の工程で衝突検出を行います。
2. GCS（XCom）でwritesetを送信し、全ノードで同一順序でトランザクションが配信されます。
3. 各ノードは受信したwritesetを、自ノードが保持する確定済みのwritesetと照合して認証します。ここで衝突がある場合はAbortされ、そのトランザクションは失敗します。
4. クラスタ内の過半数ノードで認証されるとコミットが確定し、クライアントへ成功が返ります。

このようにGroup Replicationでは、分散合意アルゴリズムによって過半数ノードが認証したことをもってコミットが確定します。この仕組みにより、たとえば3台構成のクラスタで1ノードに障害が発生した場合でも、過半数の2ノードが生きていれば安全に動作を継続することができます。

Group Replicationクラスタ作ってみた

Group Replicationを試すために、シンプルなクラスタを作成する方法を説明します。ここではMySQLのバージョンは8.4.6で試しています。

まずは全ノードで必要な設定を確認します。server_idや各ノードのIPアドレスは環境に合わせて書き換えてください。また、Group Replicationのデフォルト内部通信用ポートは33061なので、ノード間で疎通できる必要があります。

MySQLの設定に以下を記載して、全ノードで再起動してください。

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON

# サーバーごとにユニークな値
server_id=1

plugin_load_add=group_replication.so
group_replication_group_name="FD30F2F9-F60E-450A-A212-794B48CA2583"
group_replication_start_on_boot=OFF
group_replication_local_address="node1:33061"
group_replication_group_seeds="node1:33061,node2:33061,node3:33061"
group_replication_single_primary_mode=ON
group_replication_enforce_update_everywhere_checks=OFF

次に、Group Replication用のユーザーを作成します。

mysql> CREATE USER repl@'%' IDENTIFIED BY 'P@ssword123';
Query OK, 0 rows affected

mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
Query OK, 0 rows affected

1台目のノードを起動します。1台目はまだクラスタが存在しない状態のため、bootstrapで起動する必要があります。group_replication_bootstrap_group=ONを設定することで、新しいグループを作成する起動手順が実行されます。この時点では1台のみでGroup Replicationが開始します。

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected

mysql> START GROUP_REPLICATION USER='repl', PASSWORD='P@ssword123';
Query OK, 0 rows affected

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | fba696d8-ac21-11f0-bcd0-dab3cd90a550 | node1       | 3306        | ONLINE       | PRIMARY     | 8.4.6          | XCom                       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+

1 row in set

残りのノードを起動します。

mysql> RESET BINARY LOGS AND GTIDS;
Query OK, 0 rows affected

mysql> START GROUP_REPLICATION USER='repl', PASSWORD='P@ssword123';
Query OK, 0 rows affected

以下のクエリでGroup Replicationのメンバーが表示されていれば、正常にGroup Replicationクラスタが稼働しています。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | fba67f36-ac21-11f0-a166-16e41ed03440 | node2       | 3306        | ONLINE       | SECONDARY   | 8.4.6          | XCom                       |
| group_replication_applier | fba696d8-ac21-11f0-bcd0-dab3cd90a550 | node1       | 3306        | ONLINE       | PRIMARY     | 8.4.6          | XCom                       |
| group_replication_applier | fba95521-ac21-11f0-9cec-161bab4c2011 | node3       | 3306        | ONLINE       | SECONDARY   | 8.4.6          | XCom                       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+

3 rows in set

mysql> SELECT * FROM performance_schema.replication_group_member_stats;
+---------------------------+----------------------+--------------------------------------+-----------------------------+----------------------------+--------------------------+------------------------------------+------------------------------------------+-------------------------->
| CHANNEL_NAME              | VIEW_ID              | MEMBER_ID                            | COUNT_TRANSACTIONS_IN_QUEUE | COUNT_TRANSACTIONS_CHECKED | COUNT_CONFLICTS_DETECTED | COUNT_TRANSACTIONS_ROWS_VALIDATING | TRANSACTIONS_COMMITTED_ALL_MEMBERS       | LAST_CONFLICT_FREE_TRANSA>
+---------------------------+----------------------+--------------------------------------+-----------------------------+----------------------------+--------------------------+------------------------------------+------------------------------------------+-------------------------->
| group_replication_applier | 17610118930440834:11 | fba67f36-ac21-11f0-a166-16e41ed03440 | 0                           | 0                          | 0                        | 0                                  | fba696d8-ac21-11f0-bcd0-dab3cd90a550:1-7 |                          >
| group_replication_applier | 17610118930440834:11 | fba696d8-ac21-11f0-bcd0-dab3cd90a550 | 0                           | 0                          | 0                        | 0                                  | fba696d8-ac21-11f0-bcd0-dab3cd90a550:1-7 |                          >
| group_replication_applier | 17610118930440834:11 | fba95521-ac21-11f0-9cec-161bab4c2011 | 0                           | 0                          | 0                        | 0                                  |                                          |                          >
+---------------------------+----------------------+--------------------------------------+-----------------------------+----------------------------+--------------------------+------------------------------------+------------------------------------------+-------------------------->

3 rows in set

まとめ

本記事では、Group Replicationの基本的な仕組みと簡単な構築方法について説明しました。Group Replicationは高可用性や自動フェイルオーバーといった利点がある一方、特有の制限事項や、従来のSource/Replica構成とは前提や運用方法が大きく異なる点に注意が必要です。これらを踏まえつつ、要件を満たせる場合には有力な選択肢です。