公式のドキュメントを読みながら素振りしました。
グループレプリケーションでは、グループのメンバシップ管理、ノードの障害検出、追加ノードの同期、などが自動で行われます。一方でアプリケーションからの接続先をルーティングするような機能はないため、アプリケーションがクラスタのどのノードに接続するかの制御には別のなにかが必要です（MySQL Router とか HAProxy とか）。
Configuration
グループレプリケーションのための my.cnf の抜粋です。
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64
plugin_load=group_replication.so
group_replication_group_name="470b4daf-6c34-415f-97ad-68cf76ef24e7"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.88.11:6606"
group_replication_group_seeds= "192.168.88.11:6606,192.168.88.12:6606,192.168.88.13:6606"
group_replication_bootstrap_group=off
group_replication_recovery_get_public_key=ON
plugin_load=group_replication.so を指定しているのでサーバ起動時にグループレプリケーションのプラグインがロードされます。
後から INSTALL PLUGIN する場合は group_replication_* パラメータは loose-group_replication_* のように loose- をつけておかないと存在しないパラメータのエラーで起動がコケます。
MySQL 8.0 で作成されたユーザーはデフォルトで caching_sha2_password という認証方法を使うため、グループレプリケーションではいろいろ準備が必要なようなのですが、group_replication_recovery_get_public_key=ON を指定すればその準備が省略できます。ただし中間者攻撃に対して脆弱になります。
default_authentication_plugin=mysql_native_password とかでデフォルトの認証方法を変えておくか、ユーザーを作成するときに mysql_native_password を明示しておいても良いのかもしれません、通信経路が安全であることが間違いないなら。
docker-compose
docker-compose.yml
version: '3.4'
services:
sv01:
image: mysql:8
container_name: sv01
hostname: sv01
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 1
MYSQL_DATABASE: test
MYSQL_PS1: "sv01> "
networks:
mysql:
ipv4_address: 192.168.88.11
command:
- --server_id=1
- --gtid_mode=ON
- --enforce_gtid_consistency=ON
- --binlog_checksum=NONE
- --relay_log=relay-bin
- --transaction_write_set_extraction=XXHASH64
- --plugin-load=group_replication.so
- --group_replication_group_name=470b4daf-6c34-415f-97ad-68cf76ef24e7
- --group_replication_start_on_boot=off
- --group_replication_local_address=192.168.88.11:6606
- --group_replication_group_seeds=192.168.88.11:6606,192.168.88.12:6606,192.168.88.13:6606
- --group_replication_bootstrap_group=off
- --group_replication_recovery_get_public_key=ON
sv02:
image: mysql:8
container_name: sv02
hostname: sv02
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 1
MYSQL_DATABASE: test
MYSQL_PS1: "sv02> "
networks:
mysql:
ipv4_address: 192.168.88.12
command:
- --server_id=2
- --gtid_mode=ON
- --enforce_gtid_consistency=ON
- --binlog_checksum=NONE
- --relay_log=relay-bin
- --transaction_write_set_extraction=XXHASH64
- --plugin-load=group_replication.so
- --group_replication_group_name=470b4daf-6c34-415f-97ad-68cf76ef24e7
- --group_replication_start_on_boot=off
- --group_replication_local_address=192.168.88.12:6606
- --group_replication_group_seeds=192.168.88.11:6606,192.168.88.12:6606,192.168.88.13:6606
- --group_replication_bootstrap_group=off
- --group_replication_recovery_get_public_key=ON
sv03:
image: mysql:8
container_name: sv03
hostname: sv03
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 1
MYSQL_DATABASE: test
MYSQL_PS1: "sv03> "
networks:
mysql:
ipv4_address: 192.168.88.13
command:
- --server_id=3
- --gtid_mode=ON
- --enforce_gtid_consistency=ON
- --binlog_checksum=NONE
- --relay_log=relay-bin
- --transaction_write_set_extraction=XXHASH64
- --plugin-load=group_replication.so
- --group_replication_group_name=470b4daf-6c34-415f-97ad-68cf76ef24e7
- --group_replication_start_on_boot=off
- --group_replication_local_address=192.168.88.13:6606
- --group_replication_group_seeds=192.168.88.11:6606,192.168.88.12:6606,192.168.88.13:6606
- --group_replication_bootstrap_group=off
- --group_replication_recovery_get_public_key=ON
sv04:
image: mysql:8
container_name: sv04
hostname: sv04
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 1
MYSQL_DATABASE: test
MYSQL_PS1: "sv04> "
networks:
mysql:
ipv4_address: 192.168.88.14
command:
- --server_id=4
- --gtid_mode=ON
- --enforce_gtid_consistency=ON
- --binlog_checksum=NONE
- --relay_log=relay-bin
- --transaction_write_set_extraction=XXHASH64
- --plugin-load=group_replication.so
- --group_replication_group_name=470b4daf-6c34-415f-97ad-68cf76ef24e7
- --group_replication_start_on_boot=off
- --group_replication_local_address=192.168.88.14:6606
- --group_replication_group_seeds=192.168.88.11:6606,192.168.88.12:6606,192.168.88.13:6606
- --group_replication_bootstrap_group=off
- --group_replication_recovery_get_public_key=ON
networks:
mysql:
driver: bridge
ipam:
driver: default
config:
- subnet: 192.168.88.0/24
docker-compose で開始してコンテナに入ります。
docker-compose up -d sv01 sv02 sv03
docker-compose exec sv01 mysql
docker-compose exec sv02 mysql
docker-compose exec sv03 mysql
ユーザーの作成とバイナリログのリセット
プラグインがロードされていることを確認します。
show plugins;
レプリケーションユーザーを作ります。
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
レプリケーションチャンネル group_replication_recovery に↑で作成したユーザーの資格情報を使うように設定します。
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
docker-compose up でデータベースが初期化された時点でバイナリログにいろいろ書き込まれているので、そのままだとレプリケーションを開始したときに競合するので、バイナリログをリセットしておきます。
RESET MASTER;
なお、レプリケーションユーザーの作成などの、すべてのノードで個別に実行するためレプリケーションされたくないクエリは set sql_log_bin = 0|1 とかでバイナリログの ON/OFF を制御しつつクエリを実行するのが普通のようです。ただ、初回のセットアップでは「すべてのノードでいろいろ準備→RESET MASTER→レプリケーション開始」の方がわかりみがあるきがするので、いつもそうしてます。
グループレプリケーションの開始
グループを作成してグループレプリケーションを開始します。この作業は最初の１台だけで行います。
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
グループのメンバーを確認します。この時点では sv01 の１台しかありません。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv01 | 3306 | ONLINE | PRIMARY |
+-------------+-------------+--------------+-------------+
残りのノードでも開始します。このとき group_replication_bootstrap_group=ON を指定しません。指定すると同じ名前の別のグループが作成されてしまいます。
START GROUP_REPLICATION;
グループのメンバーを確認します。うまくグループに参加できれいればどのノードで実行しても同じ結果が返ります。最初のノードである sv01 がプライマリになっています。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv01 | 3306 | ONLINE | PRIMARY |
| sv03 | 3306 | ONLINE | SECONDARY |
| sv02 | 3306 | ONLINE | SECONDARY |
+-------------+-------------+--------------+-------------+
sv01 で適当にデータを入れてみます。
USE test;
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
INSERT INTO t1 VALUES (1, 'Luis');
他のノードにレプリケーションされています。
USE test;
select * from t1;
プライマリ以外のノードは読み込み専用になってるので更新のトランザクションはエラーになります。
INSERT INTO t1 VALUES (2, 'xx');
グループにインスタンスを追加
新しくノードを追加します。
docker-compose up -d sv04
docker-compose logs -f sv04
docker-compose exec sv04 mysql
プラグインがロードされていることを確認します。
show plugins;
レプリケーションユーザーを作って、バイナリログをリセットして、グループレプリケーションを開始します。
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
RESET MASTER;
START GROUP_REPLICATION;
新しいノードが追加されるとランダムに選ばれたグループのメンバー（ドナー）からデータの同期が行われ（リカバリプロセス）、同期が完了するとオンラインのメンバーとして使用できるようになります。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
USE test;
select * from t1;
運用中のグループにインスタンスを追加
リカバリプロセスは MySQL の通常のレプリケーションを利用して行われます。なので必要なバイナリログがグループのすべてのメンバーで既にパージされているとリカバリプロセスは失敗します。
グループのすべてのメンバからバイナリログをパージします。
flush logs;
purge binary logs before now();
show binlog events;
新しいインスタンスを開始して、
docker-compose rm -fsv sv04
docker-compose up -d sv04
docker-compose logs -f sv04
docker-compose exec sv04 mysql
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
RESET MASTER;
START GROUP_REPLICATION;
ログに次のようなものがたくさん出力されます。
[ERROR] [MY-010557] [Repl] Error reading packet from server for channel 'group_replication_recovery': Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. To find the missing transactions, see the master's error log or the manual for GTID_SUBTRACT. (server_errno=1236)
[ERROR] [MY-013114] [Repl] Slave I/O for channel 'group_replication_recovery': Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. To find the missing transactions, see the master's error log or the manual for GTID_SUBTRACT.', Error_code: MY-013114
メンバーのリストを見てみると、追加はされていますが MEMBER_STATE が RECOVERING のままです。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv04 | 3306 | RECOVERING | SECONDARY |
| sv01 | 3306 | ONLINE | PRIMARY |
| sv03 | 3306 | ONLINE | SECONDARY |
| sv02 | 3306 | ONLINE | SECONDARY |
+-------------+-------------+--------------+-------------+
しばらくと MEMBER_STATE は ERROR になります。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv04 | 3306 | ERROR | |
+-------------+-------------+--------------+-------------+
他のメンバーからは見えなくなります。
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv01 | 3306 | ONLINE | PRIMARY |
| sv03 | 3306 | ONLINE | SECONDARY |
| sv02 | 3306 | ONLINE | SECONDARY |
+-------------+-------------+--------------+-------------+
グループレプリケーションを開始した直後の、すべてのバイナリログがまだ残っている状態でインスタンスを追加するようなときは別として、運用中のグループにノードを追加するときは追加前に mysqldump 的なことが必要です。
公式のドキュメントだと MySQL Enterprise Backup を使用する例が記載されていましたが、mysqldump でも良いと思うし、データディレクトリの rsync（auto.cnf に注意）でも大丈夫だと思います。
試しに mysqldump してみます。
docker-compose rm -fsv sv04
docker-compose up -d sv04
docker-compose logs -f sv04
docker-compose exec -T sv04 mysql <<'SQL'
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
RESET MASTER;
SQL
docker-compose exec -T sv03 mysqldump \
--all-databases --single-transaction --triggers --routines --events |
docker-compose exec -T sv04 mysql
docker-compose exec sv04 mysql
show master status の Executed_Gtid_Set が他のノードと同じになっていれば大丈夫です。
show master status;
+---------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+------------------------------------------+
| binlog.000001 | 151 | | | 470b4daf-6c34-415f-97ad-68cf76ef24e7:1-6 |
+---------------+----------+--------------+------------------+------------------------------------------+
グループレプリケーションを開始できます。
START GROUP_REPLICATION;
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+-------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |
+-------------+-------------+--------------+-------------+
| sv04 | 3306 | ONLINE | SECONDARY |
| sv01 | 3306 | ONLINE | PRIMARY |
| sv03 | 3306 | ONLINE | SECONDARY |
| sv02 | 3306 | ONLINE | SECONDARY |
+-------------+-------------+--------------+-------------+
IPアドレスのホワイトリスト
MySQL の設定で group_replication_group_seeds にグループのインスタンスのアドレスを羅列していますが、別にグループのすべてのインスタンスが羅列されている必要はありません。
この設定は、インスタンスでグループレプリケーションを開始したときに、どこからグループの情報を取得するかの設定です。なのでグループ内の生きているメンバーのいずれかが指定されていれば大丈夫です。なので、グループへのインスタンスの追加は group_replication_group_seeds をいじらなくてもできます。
一方、グループに参加できるアドレスのホワイトリストの設定もあって（group_replication_ip_whitelist）、そこに含まれないアドレスのインスタンスはグループのインスタンスとの通信が拒否されます。ただし、デフォルトでサーバの I/F のサブネットが追加されるので、複数のサブネットにインスタンスが分散されるとかではない限りはデフォルトのままで良さそうです。
ノードの故障
おもむろにプライマリノードを強制終了します。
docker-compose kill -s KILL sv01
他のノード（sv02 とか）で次のようにログが表示されます。
[Warning] [MY-011493] [Repl] Plugin group_replication reported: 'Member with address sv01:3306 has become unreachable.'
[Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: sv01:3306'
メンバの一覧を観てみると、sv01 がなくなって sv04 がプライマリになってました。
SELECT * FROM performance_schema.replication_group_members;
Monitoring Group Replication
グループのメンバやレプリケーションの詳細は下記のようにパフォーマンススキーマから得られます。
select * from performance_schema.replication_group_member_stats \G
select * from performance_schema.replication_group_members;
select * from performance_schema.replication_connection_status \G
select * from performance_schema.replication_applier_status;
レプリケーションチャンネルには次の用途の2つが作成されています。
group_replication_recovery
- 分散リカバリフェーズ（リカバリプロセス）で使用される
- ノードを追加したときや故障ノードが復帰したときの同期用
group_replication_applier
- グループで実行されたトランザクションを適用するために使用される
- 要するに平時のトランザクションのレプリケーション
グループのメンバに関するパフォーマンステーブルのビューについて。
replication_group_member_stats
- メンバーごとの待機中のトランザクション数とか処理済トランザクション数とかの統計
- 特定のメンバーが遅れているとかでキューに溜まってるのを監視したりするのに使える
replication_group_members
replication_group_members で表示されるメンバーのステータス。
ONLINE
RECOVERING
OFFLINE
- メンバーはグループに属していない
- プラグインがロード済でグループレプリケーションか開始していないとき
ERROR
- リカバリプロセスやトランザクションの適用中にエラー
UNREACHABLE
サービス監視とかするなら ONLINE 以外はなにかしら異常とみなして良さそうです。
Deploying in Multi-Primary or Single-Primary Mode
グループレプリケーションにはシングルプライマリモードとマルチプライマリモードがあります。デフォルトはシングルプライマリです。
グループのメンバーの中でシングルとマルチは混在できません。切り替えるためにはグループレプリケーション自体を再構成する必要があります。
マルチプライマリモードにすると、次のようなステートメントのチェックが行われるようになります。
- トランザクションが SERIALIZABLE 分離レベルで実行されるとコミットが失敗する
- CASCADE の外部キーを持つテーブルに対してトランザクションを実行するとコミットに失敗する
これらのチェックは group_replication_enforce_update_everywhere_checks を FALSE にすると無効にできます。もちろん無効にするとノード間でデータ不整合が起こる可能性が生じると思います。
Single-Primary Mode
デフォルトのシングルプライマリモードでは、グループのただ一つのメンバーだけがプライマリで、それ以外は super-read-only=ON が設定されて読み取り専用になります。
プライマリがコケたときに新しいプライマリの選出は group_replication_member_weight で重みつけできます。ただしグループ内で MySQL のバージョンに差異があると下位メジャーバージョンのものから優先的に選択されます。
プライマリがコケた後、クライアントアプリケーションを再ルーティングする前に、新しいプライマリがレプリケーションに関係するリレーログを適応しきるのを待ったほうが良いです。これは普通のレプリケーションでも同じで、リレーログが適応し切る前にクライアントを新しいプライマリにルーティングすると、クライアントからの更新とリレーログによる更新が競合する可能性があります。
プライマリとなっているメンバーの検索は performance_schema.replication_group_members テーブルの MEMBER_ROLE を見ればわかります。
Tuning Recovery
新規ノードの追加や故障ノードが復帰するとき、グループのメンバからランダムで１つが選ばれて、そのノードからデータを取得する。この処理はリカバリプロセスと呼ばれて、選ばれたノードはドナーと呼ばれる。
ドナーへの接続が失敗したときは自動的に別のドナーが選択されて接続が再試行される。接続のリトライの限界に達するとリカバリプロセスはエラーで終了する。
リカバリプロセスでは単なる接続エラーだけではなく、いろいろなエラーを検出して別のドナーで再試行が行われる。
- パージされたデータ
- ドナーでリカバリに必要なデータが既にパージされている
- 重複データ
- 新しいノードが既に持っているデータと、ドナから同期されるデータとが競合したとき
- 他のドナーには切り替えずにエラーにすることも考えられるけど、不均質なグループではあるメンバーは競合するトランザクションを持っていて、あるメンバーは競合するトランザクションを持っていない可能性があるため、このエラーが発生したときも他のドナーで再試行されます
- その他のエラー
- リカバリスレッドがコケたとき・・えーとまあなんかエラー？です
リカバリプロセスは普通のMySQLレプリケーションの実装に依存しているため、ここで説明した再試行とは別に、普通のMySQLレプリケーションとしての再試行も行われることがある。
リカバリの再試行回数は group_replication_recovery_retry_count パラメータで設定できる。
group_replication_recovery_reconnect_interval で再試行のインターバルを設定できる。再試行の都度、毎回インターバルが挟まれるわけではなく、すべてのドナーで一通り失敗したときだけインターバルが挟まれて次のドナー（一度失敗している）で再試行される。
Network Partitioning
クオラムのためにグループの過半数が生きている必要がある。ただしサーバがグループから自発的に去ったときはグループのメンバに去ることが伝えられるので、その時点でグループが再構成されるのでクオラム数も再計算される。
クオラム低下による停止からの復帰の方法。まず、生きてるノードでアドレスを確認して、
SELECT @@group_replication_local_address;
グループのメンバシップを強制的に変更する。
SET GLOBAL group_replication_force_members="192.168.88.11:6606,192.168.88.12:6606";
Group Replication Requirements
グループレプリケーションに使用するサーバの要件。
- InnoDB ストレージエンジン
- 主キー
- トランザクションの競合の検出のために主キーが必要です
- IPv4 ネットワーク
- ネットワークパフォーマンス
- それなりに太い帯域とそれなりに低いレイテンシが前提です
制限
認証プロセス？（トランザクションのコミット時にグループのメンバで合意を得るプロセス）ではギャップロックが利用できない（InnoDB の外部ではギャップロックに関する情報を利用できないため）。なのでトランザクション分離レベルには READ COMMITTED を使うことをおすすめする（たぶん要するにトランザクションがグループに伝播されるときにトランザクションが発生したノード以外ではギャップロックが利かないということだと思います。それで困るのはマルチプライマリのときだけだと思うのでシングルプライマリなら関係ないように思います）。
LOCK TABLES や GET_LOCK() は使用できない（これもシングルプライマリなら関係ないように思います。プライマリでは利きますよね？ というか LOCK TABLES とか GET_LOCK() とかなんて普段使わないですね。。。）。
マルチプライマリモードでは SERIALIZABLE 分離レベルはサポートしていない。
マルチプライマリモードでは同じオブジェクトに対して異なるサーバで DDL と DML が同時に実行されると DDL の競合が検出されないリスクがある？
マルチプライマリモードでは CASCADE を指定した外部キー制約をサポートしていない。カスケード操作が行われるときに検出できない競合が生じることがあるため。なのでマルチプライマリモードでは group_replication_enforce_update_everywhere_checks を有効にすることをおすすめする。シングルプライマリモードなら問題ない。
グループ内での複製に5秒以上を要するような通信があるとグループ内の通信の失敗を引き起こす可能性がある。LOAD DATA INFILE などで使用するファイルを小さく分割するなどの対応が必要。
マルチプライマリモードでは SELECT .. FOR UPDATE でデッドロックすることがある。これはグループのメンバー間でロックが共有されないため。
（SELECT .. FOR UPDATE は普通にデッドロックする可能性はあると思うのだけど・・どういうこと？）
グローバルレプリケーションフィルタは使用できない。一部のメンバーでトランザクションをフィルタするとグループが一貫のある状態で同期できなくなるため。グループ外のサーバとのレプリケーションなどのグループレプリケーションに直接関係しないレプリケーションチャンネルになら使用できる。
（いわゆる replicate-do-db とかのことだと思われる）
さいごに
GTID レプリケーションと mysqlfailover に毛が生えたようなものかと思ってたんですけど
とかを見るに単純にバイナリログを転送しているだけではなさそうです。ただシングルプライマリだと実質単純にバイナリログを転送しているだけになりそうな気もするので、グループレプリケーションの最大の旨味はマルチプライマリモードですかね？ 最もノードのヘルスチェックやフェイルオーバーの自動化の面だけでも十分メリットあると思うので今後使えそうなら使っていきたいかも。
それと、グループ全体をシャットダウンすると group_replication_bootstrap_group が再び必要になります。これはちょっと面倒ですね。いわゆる本番環境なら止めることはないので良いですけど、検証環境とかで上げたり下げたりすることがあると運用が面倒そうです。
