2.组复制使用入门
- 2.1 部署单主模型的组复制

2.Getting Started

组复制使用入门

MySQL组复制是通过MySQL插件形式提供的，复制组中的所有节点都需要安装和配置该插件。本节介绍创建一个最少3节点的组复制所需的详细步骤。

2.1 Deploying Group Replication in Single-Primary Mode

部署单主模型的组复制

组中的每个mysql实例都可以运行在一个独立的物理主机上，也可以运行在同一主机上。本节介绍如何在同一主机上创建一个包含3实例的组复制。这意味着需要3个数据目录，每个实例一个数据目录。

本节介绍如何获取并部署带有组复制插件的MySQL Server，在创建复制组之前如何配置每个实例，以及如何通过Performance Schema monitoring来验证配置是否正确。

2.1.1 Deploying Instances for Group Replication

部署MySQL实例

第一步是部署3个MySQL Server实例。组复制插件是内置在MySQL 5.7.17 + 版本中的。更多关于MySQL插件的内容，参见 Section 5.5 “MySQL Server Plugins”。此处假定MySQL Server已经下载好且解压在名为 mysql-5.7 的目录下。由于3个实例配置在同一主机上，因此每个MySQL Server实例都需要指定一个单独的数据目录。在名为 data 的目录下创建这些数据目录并逐一初始化。

mkdir data
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s1
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s2
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s3

data/s1, data/s2, data/s3 是已经初始化的数据目录，包含了mysql系统数据库和表等。更多关于初始化的内容，见Section 2.10.1.1 “Initializing the Data Directory Manually Using mysqld”。

警告
不要使用在生产环境中使用--initialize-insecure进行初始化，此处使用该选项仅是出于简化操作的原因。

2.1.2 Configuring an Instance for Group Replication

配置组复制实例

本节解释要使用组复制所需要进行的设置。关于组复制的限制，见7.2 组复制的限制(局限性)。

Group Replication Server Settings

组复制节点的选项设置

要使用MySQL的组复制，必须要正确配置MySQL实例。建议将配置保存在my.cnf文件中。除非另有说明，否则下面的配置操作都是称为s1 实例对应的配置。下面是一个节点的配置示例：

[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s1
basedir=<full_path_to_bin>/mysql-5.7/
port=24801
socket=<full_path_to_sock_dir>/s1.sock

这些配置指定了MySQL Server使用的数据目录为之前创建的/data/s1，并且指定了该实例的监听端口。

注意
这里使用的24801端口是非默认端口，因为是在同一主机上配置3个实例。如果3个实例是配置在不同主机上，则无需手动指定端口号。

Replication Framework

复制框架

下面的选项是开启MySQL组复制之前所需的配置。

server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW

上面配置了server_id为1，并启用了基于全局事务ID(GTID)的复制类型，并指定使用表而非文件来存储复制相关的元数据。此外，还开启了基于行格式(row-based)的二进制日志，并禁用了二进制日志的事件checksum。更多关于组复制的限制，见7.1 组复制的要求。

Group Replication Settings

组复制相关的设置

此时my.cnf中的配置已经能让MySQL复制运行起来。下面是配置组复制的部分选项。

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

注意
上面的组复制变量中使用了前缀loose-，这表示启动MySQL实例时如果没有成功加载组复制插件也继续启动MySQL。(译者加：上面几项设置off是为了后面手动在第一个节点上启动这几个配置，强烈建议如此)

第 1 行表示节点必须收集每个事务的写集(write set)，并使用 XXHASH64 哈希算法将其编码为hash值。
第 2 行用来告诉插件，有一个名为"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"的组需要加入，或者需要创建。
第 3 行告诉插件，在启动MySQL实例时不要自动启动组复制功能。
第 4 行告诉插件，该实例使用 127.0.0.1 或 localhost 以及24901端口作为组中成员之间的通信地址。选项group_replication_local_address配置的本地地址必须能和组中其他所有成员通信。例如，如果组中每个MySQL实例都单独安装在一台物理机上，那么必须不能指定回环地址。选项group_replication_local_address的推荐端口是33061，但因为这里我们将3个实例配置在一台主机上，所以使用24901-24903这3个端口。
第 5 行告诉插件，如果节点要加入该组，需要联系这些主机。这些是种子成员 (seed members)，当节点要连接该组时需要使用这些成员。在某节点要加入组时，需要联系其中的一个(种子)，然后请求组重新配置成员列表，以允许在组中接受该节点。注意，不需要在该选项中列出组中的所有成员，只需要列出节点希望加入组时应该联系的服务器列表。
组中第一个节点启动时不需要考虑这个选项，因为它用来启动复制组，它是组中的第一个成员，它负责引导组。第二个节点加入组时，需要询问组中唯一已启动的节点，然后组被扩展。第三个节点加入组时，需要询问前面两个节点中的任何一个，然后组再次扩展。如果还有第4个、第5个新节点要加入，则需要询问这3个节点中的任何一个，更多节点依此类推。

警告
当多个节点在同一时刻加入组时，需要确保它们指向的种子成员已经在组中。不要指向那些也正在加入组的种子成员，因为联系它们时，它们自身可能还没成功加入组。

首先启动引导成员，并让它来创建组，这是一个好习惯。然后将它作为其他成员加入组时的种子成员。

不应该在创建组的时候同时加入多个成员。虽然可能允许这样的操作，但因为它们是争抢的行为，这可能会导致加入组的行为终止或超时。

第 6 行告诉插件是否要引导该组。

重要
该选项在任何时候都必须只能在一个节点上使用，通常用在第一次启动组的节点上(或者整个组下线，然后再重新上线的情况)。如果多次引导组，例如多个节点上配置了该选项，这可能会人为地创建一个脑裂场景，因为这时会存在名称相同但实际不同的两个或多个组。应该在第一个节点加入组后禁用该选项。

配置组中的其他节点是类似的。你只需修改几项指定的选项 (例如server_id, datadir, group_replication_local_address)。后文将会对此说明。

2.1.3 User Credentials

用户凭证

在成员需要加入组之前，组复制使用异步复制协议进行分布式恢复、组成员信息的同步。分布式恢复过程依赖于一个名为group_replication_recovery的复制通道，它用于成员之间传输事务。因此，你必须设置一个权限正确的专门用于复制的用户，以便组复制在成员间建立正确的用于分布式恢复的复制通道。

启动实例：

mysql-5.7/bin/mysqld --defaults-file=data/s1/s1.cnf

创建一个具有REPLICATION-SLAVE权限的MySQL用户。该操作不应该写进binlog中，以免被其他节点复制走(译注：实际上，个人建议写进binlog让其他节点复制走，否则第一个种子节点离组后，再加入新成员时讲无法建立通道。本文档的方法是在每个节点上手动创建复制用户)。下面的示例中，建立的用户是rpl_user，密码是rpl_pass。当配置你自己的服务器时，应该使用合适的用户名和密码。连接到 s1 实例后，执行以下语句：

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER rpl_user@'%';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;

配置了上述用户后，使用CHANGE MASTER TO 语句指定服务器下次恢复状态时所使用通道group_replication_recovery的凭据。执行下述语句，替换rpl_user和rpl_pass为你自己创建的用户名和密码。

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' \\
FOR CHANNEL 'group_replication_recovery';

分布式恢复是节点加入组时的第一个步骤。如果这些凭据没有正确设置，节点将无法执行恢复的过程，从而会与其他成员重新开始同步，因而最终加组失败。类似地，如果成员通过节点的hostname无法正确识别其他成员，恢复过程也会失败。所以建议运行MySQL的节点合理配置具有唯一性的hostname。该hostname可以在performance_schema.replication_group_members表中的Member_host列进行验证。如果组中多个成员使用一个默认操作系统设置的hostname，有一定可能会无法正确解析成员的地址，从而导致新节点加组失败。这种情况下，可以使用report_host来配置每一个节点的唯一外部化 hostname。

2.1.4 Launching Group Replication

登陆复制组

在 s1配置完成并启动后，可以安装组复制插件了。连接到该实例，输入下述语句：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

要检查插件是否安装成功，使用SHOW PLUGINS;语句，安装成功的输出结果看上去大概是这样的：

mysql> SHOW PLUGINS;
+----------------------+----------+--------------------+----------------------+-------------+
| Name                 | Status   | Type               | Library              | License     |
+----------------------+----------+--------------------+----------------------+-------------+
| binlog               | ACTIVE   | STORAGE ENGINE     | NULL                 | PROPRIETARY |
(...)
| group_replication    | ACTIVE   | GROUP REPLICATION  | group_replication.so | PROPRIETARY |
+----------------------+----------+--------------------+----------------------+-------------+

要启动组，需要指示s1实例引导这个组，然后启动组复制。引导操作应当只在一个节点上进行，建议在启动组中第一个成员时引导。这就是为什么引导组的配置选项没有保存在配置文件中。如果将其配置在配置文件中，每当重启该节点时都将自动引导具有完全相同名称的第二个组。同样的原因，将其设置为ON来停止和重启插件。

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

当START GROUP_REPLICATION语句返回后，就表示组已经启动了。你可以检查该组是否已经创建，组中是否已有一个成员：

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost      |       24801 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

该表中的信息表明该组中有一个唯一标识符为ce9be252-2b71-11e6-b8f4-00212844f856的成员，它的状态是ONLINE，主机名为myhost(译注：这不一定真的是该主机的主机名，可能是report_host设置的主机名)，监听客户端连接的端口为24801。

为了演示该主机确实在组中，且能处理请求，现在创建一张表，并插入一些内容：

mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
mysql> INSERT INTO t1 VALUES (1, 'Luis');

检查表t1的内容以及二进制日志。

mysql> SELECT * FROM t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |   4 | Format_desc    |         1 |         123 | Server ver: 5.7.19-gr080-log, Binlog ver: 4                        |
| binlog.000001 | 123 | Previous_gtids |         1 |         150 |                                                                    |
| binlog.000001 | 150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 | 211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 | 270 | View_change    |         1 |         369 | view_id=14724817264259180:1                                        |
| binlog.000001 | 369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 | 434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 | 495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 | 585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 | 646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 | 831 | Query          |         1 |         899 | BEGIN                                                              |
| binlog.000001 | 899 | Table_map      |         1 |         942 | table_id: 108 (test.t1)                                            |
| binlog.000001 | 942 | Write_rows     |         1 |         984 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 | 984 | Xid            |         1 |        1011 | COMMIT /* xid=38 */                                                |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

如上所见，数据库和表对象已经创建，且它们对应的DDL语句已经写入到二进制日志中。此外，数据也已经插入到了表中且写入了二进制日志中。二进制日志中条目的重要后面会说明，因为新成员要加入组并赶上组的数据时，需要进行分布式恢复，此时会执行二进制日志中的记录。

2.1.5 Adding Instances to the Group

向组中加入新实例

此刻组中已经有一个成员s1，且该成员中还有一些新数据。现在可以向组中加入前面已经配置好的两个实例来扩展组了。

Adding a Second Instance

加入第二个实例为了增加第二个实例s2，首先配置它的配置文件。该配置文件类似于前面s1的配置文件，除了数据目录、s2的端口、server_id。

[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s2
basedir=<full_path_to_bin>/mysql-5.7/
port=24802
socket=<full_path_to_sock_dir>/s2.sock
#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24902"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

类似于实例s1的操作过程，使用配置文件启动实例s2。

mysql-5.7/bin/mysqld --defaults-file=data/s2/s2.cnf

然后按照下面的过程配置恢复凭据。这些命令和前面设置实例s1时是一样的，因为用户名是组中共享的。在s2上执行如下语句：

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' \\
FOR CHANNEL 'group_replication_recovery';

安装组复制插件，并开始节点加入组的过程。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

加入s2到组中：

mysql> START GROUP_REPLICATION;

不像前面的步骤都和配置s1实例时都一样，这里有一个不同之处，你不能在启动组复制之前执行语句SET GLOBAL group_replication_bootstrap_group=ON;，因为组已经被实例 s1 创建并引导完成了。所以 s2 实例只需加入到已存在的组中即可。

再次查看表performance_schema.replication_group_members，检查 s2 实例是否在组中，且状态为ONLINE 。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost      |       24801 | ONLINE        |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost      |       24802 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

由于 s2 也被标识为ONLINE，说明它已经自动赶上了 s1 实例上的数据。执行下面的语句检查 s2 实例是否确实已经和 s1 保持同步了。

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         2 |         123 | Server ver: 5.7.17-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         2 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=30 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

可见，第二个实例已经添加到了组中，且已经自动从实例 s1 中复制了数据。根据分布式恢复过程，这意味着在 s2 成功加入组并标记为 ONLINE 之前，s2实例已经联系过 s1 实例并自动从中抓取了缺失的那部分数据。换句话说，它拷贝了 s1 实例的二进制日志中的自己缺失的那部分事务，所拷贝事务的的结束位置是它加入组那一刻的位置。

Adding Additional Instances

向复制组中添加更多的实例

再向组中添加其他实例，操作和刚才添加实例 s2 是基本类似的，除了之前提到的需要更改的一些配置。总结一下所需要执行的命令：

提供配置文件。

[mysqld]

# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-5.7/

port=24803
socket=<full_path_to_sock_dir>/s3.sock

#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW

#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24903"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

启动MySQL实例。

mysql-5.7/bin/mysqld --defaults-file=data/s3/s3.cnf

配置凭据恢复通道 group_replication_recovery channel。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' \\
FOR CHANNEL 'group_replication_recovery';

安装组复制插件并启动它。

INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;

到此为止，s3 实例已经启动并正在运行，它会试图加入组，并自动抓取组中它所缺失的那部分数据。通过检查表performance_schema.replication_group_members来确认是否一切OK。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost      |       24801 | ONLINE        |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | myhost      |       24803 | ONLINE        |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost      |       24802 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

执行下面的查询看看 s3 上的数据是否和 s1 或 s2 实例一样。

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 5.7.17-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=29 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
| binlog.000001 | 1326 | Gtid           |         1 |        1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6'  |
| binlog.000001 | 1387 | Query          |         1 |        1446 | BEGIN                                                              |
| binlog.000001 | 1446 | View_change    |         1 |        1585 | view_id=14724832985483517:3                                        |
| binlog.000001 | 1585 | Query          |         1 |        1650 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

Getting Started - malongshuai/MySQL-Group-Replication GitHub Wiki

2.Getting Started

2.1 Deploying Group Replication in Single-Primary Mode

2.1.1 Deploying Instances for Group Replication

2.1.2 Configuring an Instance for Group Replication

Group Replication Server Settings

Replication Framework

Group Replication Settings

2.1.3 User Credentials

2.1.4 Launching Group Replication

2.1.5 Adding Instances to the Group

Adding a Second Instance

Adding Additional Instances

⚠️ GitHub.com Fallback ⚠️

Getting Started - malongshuai/MySQL-Group-Replication GitHub Wiki

2.Getting Started

2.1 Deploying Group Replication in Single-Primary Mode

2.1.1 Deploying Instances for Group Replication

2.1.2 Configuring an Instance for Group Replication

Group Replication Server Settings

Replication Framework

Group Replication Settings

2.1.3 User Credentials

2.1.4 Launching Group Replication

2.1.5 Adding Instances to the Group

Adding a Second Instance

Adding Additional Instances

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️