单主模式部署组复制
组中的每个MySQL服务器实例都可以运行在独立的物理主机上，这是部署组复制的推荐方式。本节介绍如何创建具有三个 MySQL Server 实例的复制组，每个实例运行在不同的主机上。
组架构
三个服务器实例 S1、S2 和 S3 部署为互连组，客户端与每个服务器实例进行通信。
本教程介绍如何使用组复制插件获取和部署 MySQL Server、如何在创建组之前配置每个服务器实例，以及如何使用性能架构监控来验证一切是否正常工作。
MySQL Group Replication 作为 MySQL 服务器的插件提供；组中的每个服务器都需要配置和安装插件。本部分提供了详细教程，其中包含创建至少包含三个成员的复制组所需的步骤。
部署组复制实例
第一步是部署至少三个 MySQL Server 实例，此过程演示了为实例使用多个主机，名为 s1、s2 和 s3。假设每台主机上都安装了 MySQL 服务器。MySQL Server 8.0 提供组复制插件；不需要额外的软件，但插件必须安装在正在运行的 MySQL 服务器上。
在本例中，组使用了三个实例，这是创建组的最小实例数。添加更多实例可以提高组的容错能力。例如，如果该组由三名成员组成，则在一个实例发生故障时该组可以继续。但如果发生另一次故障，该组将无法再继续处理写入事务。通过添加更多实例，当组继续处理事务时可能发生故障的服务器数量也会增加。一个组中最多可以使用 9 个实例。有关详细信息 ，请参阅第 20.1.4.2 节“故障检测”。
配置组复制实例
存储引擎
对于组复制，数据必须存储在 InnoDB 事务存储引擎中（有关原因的详细信息，请参阅 第 20.3.1 节“组复制要求”）。使用其他存储引擎可能会导致组复制出错。disabled_storage_engines 按如下方式 设置 系统变量以防止使用它们：
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
请注意，在禁用存储引擎的情况下，当您将 MySQL 实例升级到仍使用mysql_upgrade 的MyISAM版本（MySQL 8.0.16 之前）时， mysql_upgrade可能会失败并出现错误。要解决此问题，您可以在运行mysql_upgrade时重新启用该存储引擎，然后在重新启动服务器时再次禁用它。有关更多信息，请参阅第 6.4.5 节“mysql_upgrade - 检查和升级 MySQL 表”。
复制框架
以下设置根据 MySQL 组复制要求配置复制。
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
这些设置将服务器配置为使用唯一标识符号 1，以启用 第 19.1.3 节“使用全局事务标识符进行复制”，并允许仅执行可以使用 GTID 安全记录的语句。
从 MySQL 8.0.20 开始，还需要进行以下设置：
binlog_checksum=NONE
此设置禁用写入二进制日志的事件的校验和，默认情况下启用。从 MySQL 8.0.21 开始，组复制支持二进制日志中存在校验和，并可以使用它们来验证某些通道上事件的完整性，因此您可以使用默认设置。有关更多详细信息，请参阅第 20.3.2 节 “组复制限制”。
如果您使用的 MySQL 版本早于 8.0.3（其中复制的默认值已改进），您还需要将这些行添加到成员的选项文件中。如果更高版本的选项文件中有任何这些系统变量，请确保按所示方式设置它们。有关更多详细信息，请参阅第 20.3.1 节 “组复制要求”。
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_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s1:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group=off
-
plugin-load-add将组复制插件添加到服务器在启动时加载的插件列表中。在生产部署中，这比手动安装插件更可取。 -
配置
group_replication_group_name告诉插件它正在加入或创建的组被命名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。的值
group_replication_group_name必须是有效的 UUID。您可以使用SELECT UUID()它来生成一个。此 UUID 构成 GTID 的一部分，当组成员从客户端接收事务以及组成员内部生成的视图更改事件写入二进制日志时，将使用 GTID。 -
配置该
group_replication_start_on_boot变量以off指示插件在服务器启动时不自动启动操作。这在设置组复制时很重要，因为它确保您可以在手动启动插件之前配置服务器。配置成员后，您可以进行设置group_replication_start_on_boot，on以便组复制在服务器启动时自动启动。 -
配置
group_replication_local_address设置成员用于与组中其他成员进行内部通信的网络地址和端口。组复制使用此地址进行涉及组通信引擎（XCom，Paxos 变体）远程实例的内部成员到成员连接。重要的
组复制本地地址必须与用于 SQL 客户端连接的主机名和端口不同，这些由 MySQL 服务器
hostname和port系统变量定义。它不得用于客户端应用程序。它只能用于运行组复制时组成员之间的内部通信。配置的网络地址
group_replication_local_address必须可由所有组成员解析。例如，如果每个服务器实例位于具有固定网络地址的不同计算机上，则可以使用该计算机的 IP 地址，例如 10.0.0.1。如果使用主机名，则必须使用完全限定名称，并确保它可通过 DNS、正确配置的/etc/hosts文件或其他名称解析进程进行解析。从 MySQL 8.0.14 开始，可以使用 IPv6 地址（或解析为它们的主机名）以及 IPv4 地址。组可以包含使用 IPv6 的成员和使用 IPv4 的成员的混合。有关 IPv6 网络以及 IPv4 和 IPv6 混合组的组复制支持的更多信息，请参阅 第 20.5.5 节 “对 IPv6 以及混合 IPv6 和 IPv4 组的支持”。建议的端口
group_replication_local_address是 33061。group_replication_local_address组复制将其用作复制组内组成员的唯一标识符。只要主机名或 IP 地址全部不同，您就可以对复制组的所有成员使用相同的端口，如本教程中所示。或者，您可以对所有成员使用相同的主机名或 IP 地址，只要端口全部不同，例如，如第20.2.2 节 “本地部署组复制”中所示。现有成员为组复制的分布式恢复过程向加入成员提供的连接不是由 配置的网络地址
group_replication_local_address。截至 MySQL 8.0.20，组成员向加入成员提供标准 SQL 客户端连接以进行分布式恢复，如 MySQL 服务器hostname和port系统变量所指定。从 MySQL 8.0.21 开始，组成员可以将分布式恢复端点的替代列表公布为用于加入成员的专用客户端连接。有关更多详细信息，请参见 第 20.5.4.1 节 “分布式恢复的连接”。重要的
如果加入成员无法使用 MySQL 服务器系统变量定义的主机名正确识别其他成员，则分布式恢复可能会失败
hostname。建议运行 MySQL 的操作系统使用 DNS 或本地设置正确配置唯一的主机名。服务器用于 SQL 客户端连接的主机名可以在Member_host性能架构表的列 中进行验证replication_group_members。如果多个组成员外部化操作系统设置的默认主机名，则加入成员可能无法将其解析为正确的成员地址，并且无法连接以进行分布式恢复。在这种情况下，您可以使用 MySQL 服务器的report_host系统变量来配置要由每个服务器外部化的唯一主机名。 -
配置
group_replication_group_seeds设置组成员的主机名和端口，新成员使用这些主机名和端口建立与组的连接。这些成员被称为种子成员。连接建立后，组成员信息将在性能架构表中列出replication_group_members。通常该group_replication_group_seeds列表包含hostname:port每个组成员的group_replication_local_address，但这不是强制性的，并且可以选择组成员的子集作为种子。重要的
hostname:port中列出的 是group_replication_group_seeds种子成员的内部网络地址，由 SQL 客户端连接配置group_replication_local_address，而不是hostname:port用于 SQL 客户端连接，例如性能架构表中显示的地址replication_group_members。启动组的服务器不使用此选项，因为它是初始服务器，因此它负责引导组。换句话说，引导该组的服务器上的任何现有数据都将用作下一个加入成员的数据。第二个服务器加入要求组中唯一的成员加入，第二个服务器上任何丢失的数据都将从引导成员上的捐赠者数据复制，然后组扩展。第三个服务器加入可以要求这两个服务器中的任何一个加入，数据同步到新成员，然后组再次扩展。后续服务器在加入时重复此过程。
警告
同时加入多个服务器时，请确保它们指向组中已有的种子成员。不要使用也加入该组的成员作为种子，因为在联系时他们可能尚未加入该组。
最好先启动引导程序成员，然后让它创建组。然后将其作为其他要加入的成员的种子成员。这确保了在加入其他成员时形成一个组。
不支持创建群组并同时加入多个成员。它可能会起作用，但很可能操作会发生争用，然后加入该组的行为最终会出现错误或超时。
加入成员必须使用种子成员在选项中通告的相同协议（IPv4 或 IPv6）与种子成员进行通信
group_replication_group_seeds。为了获得组复制的 IP 地址权限，种子成员上的允许列表必须包含种子成员提供的协议的加入成员的 IP 地址，或解析为该协议的地址的主机名。group_replication_local_address如果该地址的协议与种子成员公布的协议不匹配，则除了加入成员的地址或主机名之外，还必须设置并允许该地址或主机名 。如果加入成员没有适当协议的允许地址，则其连接尝试将被拒绝。有关更多信息，请参见 第 20.6.4 节 “组复制 IP 地址权限”。 -
配置指示
group_replication_bootstrap_group插件是否引导该组。在这种情况下，即使 s1 是组的第一个成员，我们也会在选项文件中将此变量设置为 off。相反，我们group_replication_bootstrap_group在实例运行时进行配置，以确保只有一名成员实际引导该组。重要的
任何时候，该
group_replication_bootstrap_group变量只能在属于某个组的一个服务器实例上启用，通常是在您第一次引导该组时（或者在整个组关闭并再次备份的情况下）。如果您多次引导该组，例如当多个服务器实例设置了此选项时，那么它们可能会创建一个人工裂脑场景，其中存在两个具有相同名称的不同组。group_replication_bootstrap_group=off始终在第一个服务器实例上线后 设置 。
本教程中描述的系统变量是启动新成员所需的配置设置，但还可以使用更多系统变量来配置组成员。这些列在 第 20.9 节“组复制变量”中。
重要的
许多系统变量（有些特定于组复制，有些则不是）是组范围的配置设置，必须在所有组成员上具有相同的值。如果组成员为这些系统变量之一设置了值，而加入成员为其设置了不同的值，则加入成员无法加入组，并返回错误消息。如果群组成员已为此系统变量设置了值，并且加入成员不支持该系统变量，则无法加入群组。这些系统变量都在 第 20.9 节“组复制变量”中进行了标识。
分布式恢复的用户凭证
组复制在将组成员加入组时使用分布式恢复过程来同步组成员。分布式恢复涉及使用名为 的复制通道将事务从捐赠者的二进制日志传输到加入成员group_replication_recovery。因此，您必须设置具有正确权限的复制用户，以便组复制可以建立直接的成员到成员的复制通道。如果组成员已设置为支持使用远程克隆操作作为分布式恢复的一部分（从 MySQL 8.0.17 开始提供），则此复制用户也将用作捐赠者上的克隆用户，并且需要正确的权限也适合这个角色。有关分布式恢复的完整描述，请参见 第 20.5.4 节“分布式恢复”。
必须使用相同的复制用户在每个组成员上进行分布式恢复。为分布式恢复创建复制用户的过程可以在二进制日志中捕获，然后可以依靠分布式恢复来复制用于创建用户的语句。或者，您可以在创建复制用户之前禁用二进制日志记录，然后在每个成员上手动创建用户，例如，如果您想避免更改传播到其他服务器实例。如果您这样做，请确保在配置用户后重新启用二进制日志记录。
重要的
如果您的组的分布式恢复连接使用 SSL，则必须在加入成员连接到捐赠者之前 在每台服务器上创建复制用户 。有关为分布式恢复连接设置 SSL 以及创建需要 SSL 的复制用户的说明，请参阅 第 20.6.3 节 “保护分布式恢复连接”
重要的
默认情况下，在 MySQL 8 中创建的用户使用 第 8.4.1.2 节“缓存 SHA-2 可插入身份验证”。如果分布式恢复的复制用户使用缓存 SHA-2 身份验证插件，并且您没有 使用SSL 进行分布式恢复连接，则将使用 RSA 密钥对进行密码交换。您可以将复制用户的公钥复制给加入成员，也可以将捐赠者配置为在请求时提供公钥。有关执行此操作的说明，请参见 第 20.6.3.1 节 “分布式恢复的安全用户凭证”。
要创建分布式恢复的复制用户，请执行以下步骤：
-
启动 MySQL 服务器实例，然后将客户端连接到它。
-
如果您想要禁用二进制日志记录以便在每个实例上单独创建复制用户，请通过发出以下语句来执行此操作：
mysql> SET SQL_LOG_BIN=0; -
创建具有以下权限的 MySQL 用户：
REPLICATION SLAVE，这是与捐赠者建立分布式恢复连接以检索数据所必需的。CONNECTION_ADMIN，这可确保在所涉及的其中一台服务器处于脱机模式时组复制连接不会终止。BACKUP_ADMIN，如果复制组中的服务器设置为支持克隆（请参见 第 20.5.4.2 节 “克隆以进行分布式恢复”）。成员需要此特权才能在分布式恢复的克隆操作中充当捐赠者。GROUP_REPLICATION_STREAM，如果 MySQL 通信堆栈正在用于复制组（请参见 第 20.6.1 节 “连接安全管理的通信堆栈”）。用户帐户需要此权限才能使用 MySQL 通信堆栈建立和维护组复制连接。
在此示例中，显示了*
rpl_user* 具有密码的 用户。*password*配置服务器时，请使用合适的用户名和密码：mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password'; mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; mysql> GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%'; mysql> GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%'; mysql> GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%'; mysql> FLUSH PRIVILEGES; -
如果您禁用了二进制日志记录，请在创建用户后立即通过发出以下语句再次启用它：
mysql> SET SQL_LOG_BIN=1; -
创建复制用户后，必须向服务器提供用户凭据以用于分布式恢复。
group_replication_recovery您可以通过使用CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）将用户凭据设置为通道的凭据来完成此操作 。或者，从 MySQL 8.0.21 开始，您可以在语句上指定分布式恢复的用户凭据START GROUP_REPLICATION。CHANGE REPLICATION SOURCE TO使用| 设置用户凭据CHANGE MASTER TO以纯文本形式存储在服务器上的复制元数据存储库中。每当组复制启动时都会应用它们，包括如果group_replication_start_on_boot系统变量设置为 则自动启动ON。- 指定的用户凭据
START GROUP_REPLICATION仅保存在内存中，并通过STOP GROUP_REPLICATION语句或服务器关闭来删除。您必须发出START GROUP_REPLICATION声明来再次提供凭据，因此您无法使用这些凭据自动启动组复制。这种指定用户凭据的方法有助于保护组复制服务器免受未经授权的访问。
有关提供用户凭据的每种方法的安全影响的更多信息，请参阅 第 20.6.3.1.3 节 “安全地提供复制用户凭据”。如果您选择使用
CHANGE REPLICATION SOURCE TO|提供用户凭据CHANGE MASTER TO语句，现在在服务器实例上发出以下语句，将*rpl_user和 替换password*为创建用户时使用的值：mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery'; Or from MySQL 8.0.23: mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery';
启动组复制
首先需要确保服务器 s1 上安装了组复制插件。如果您在选项文件中使用， plugin_load_add='group_replication.so'则组复制插件已安装，您可以继续下一步。否则，必须手动安装插件；为此，请使用mysql客户端连接到服务器，并发出如下所示的 SQL 语句：
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
重要的
用户mysql.session必须存在才能加载组复制。 mysql.session在 MySQL 8.0.2 版本中添加。如果您的数据字典是使用早期版本初始化的，则必须执行 MySQL 升级过程（请参阅第 3 章，升级 MySQL）。如果未运行升级，组复制将无法启动，并显示错误消息 尝试使用用户访问服务器时出错：mysql.session@localhost。确保该用户存在于服务器中并且在服务器更新后运行了 mysql_upgrade。
要检查插件是否已成功安装，请发出 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 |
+----------------------------+----------+--------------------+----------------------+-------------+
引导组
第一次启动一个组的过程称为引导。您可以使用 group_replication_bootstrap_group 系统变量来引导组。引导程序只能由一台服务器完成，即启动该组的服务器，并且只能执行一次。这就是选项值 group_replication_bootstrap_group 未存储在实例的选项文件中的原因。如果将其保存在选项文件中，则在重新启动时，服务器会自动引导具有相同名称的第二个组。这将导致两个不同的组具有相同的名称。同样的推理适用于将此选项设置为 来停止和重新启动插件ON。因此，要安全地引导该组，请连接到 s1 并发出以下语句：
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
或者，如果您要在语句上提供分布式恢复的用户凭据START GROUP_REPLICATION（可以从 MySQL 8.0.21 开始），请发出以下语句：
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
mysql> 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 | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+---------------+-------------+----------------+----------------------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | s1 | 3306 | ONLINE | | | XCom |
+---------------------------+--------------------------------------+-------------+-------------+---------------+-------------+----------------+----------------------------+
1 row in set (0.0108 sec)
该表中的信息确认组中存在具有唯一标识符的成员 ce9be252-2b71-11e6-b8f4-00212844f856，并且该成员ONLINE正在s1 侦听端口上的客户端连接 3306。
为了证明服务器确实在一个组中并且能够处理负载，创建一个表并向其中添加一些内容。
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: 8.0.36-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语句被写入二进制日志。此外，数据被插入表中并写入二进制日志，因此可以通过从捐赠者的二进制日志进行状态传输来进行分布式恢复。
将实例添加到组中
此时，该组中有一个成员，即服务器 s1，其中有一些数据。现在是时候通过添加之前配置的其他两台服务器来扩展该组了。
添加第二个实例
为了添加第二个实例（服务器 s2），首先为其创建配置文件。该配置与服务器 s1 所使用的配置类似，除了 server_id. 这些不同的行在下面的列表中突出显示。
[mysqld]
#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE # Not needed from 8.0.21
#
# Group Replication configuration
#
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off
与服务器 s1 的过程类似，使用就位的选项文件启动服务器。然后按如下方式配置分布式恢复凭据。这些命令与设置服务器 s1 时使用的命令相同，因为用户在组内共享。该成员需要具有在 第 20.2.1.3 节 “分布式恢复的用户凭据”中配置的相同复制用户。如果您依靠分布式恢复在所有成员上配置用户，则当 s2 连接到种子 s1 时，复制用户将被复制或克隆到 s1。如果您在 s1 上配置用户凭据时未启用二进制日志记录，并且远程克隆操作不用于状态传输，则必须在 s2 上创建复制用户。在这种情况下，连接到 s2 并发出：
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
如果您使用 CHANGE REPLICATION SOURCE TO| 提供用户凭据 CHANGE MASTER TO声明，之后发布以下声明：
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
Or from MySQL 8.0.23:
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';
提示
如果您使用的是缓存 SHA-2 身份验证插件（MySQL 8 中的默认设置），请参阅 第 20.6.3.1.1 节，“使用缓存 SHA-2 身份验证插件复制用户”。
如有必要，请安装组复制插件，请参阅 第 20.2.1.4 节 “启动组复制”。
启动组复制，s2 开始加入组的过程。
mysql> START GROUP_REPLICATION;
或者，如果您在语句上提供用于分布式恢复的用户凭据START GROUP_REPLICATION（可以从 MySQL 8.0.21 开始）：
mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
与前面在 s1 上执行的步骤相同的步骤不同，这里的不同之处在于您不需要 引导该组，因为该组已经存在。换句话说，在 s2 上 group_replication_bootstrap_group 设置为OFF，并且在启动组复制之前您不会发出命令 SET GLOBAL group_replication_bootstrap_group=ON;，因为该组已由服务器 s1 创建并引导。此时只需要将服务器s2添加到已经存在的组中即可。
提示
当组复制成功启动并且服务器加入组时，它会检查该 super_read_only变量。通过在成员的配置文件中设置super_read_only 为ON，您可以确保因任何原因启动组复制时失败的服务器不接受事务。如果服务器应作为读写实例加入组，例如作为单主组中的主实例或多主组的成员，则当该 super_read_only变量设置为 ON 时，则将其设置为 OFF加入该团体。
再次检查该 performance_schema.replication_group_members 表显示该组中现在有两台 ONLINE服务器。
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 | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE | PRIMARY | 8.0.27 | XCom |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE | SECONDARY | 8.0.27 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
当 s2 尝试加入该组时， 第 20.5.4 节“分布式恢复” 确保 s2 应用与 s1 应用的相同事务。一旦这个过程完成，s2就可以作为成员加入该组，此时它被标记为 ONLINE。换句话说，它一定已经自动追上了服务器 s1。一旦 s2 为 ONLINE，它就会开始处理与该组的事务。验证 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: 8.0.36-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 加入组的时间点开始，在 s1 上应用的事务已被复制到 s2。
添加附加实例
向组中添加其他实例本质上与添加第二台服务器的步骤顺序相同，只是必须更改配置（因为服务器 s2 必须如此）。总结一下所需的命令：
-
创建配置文件。
[mysqld] # # Disable other storage engines # disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" # # Replication configuration parameters # server_id=3 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE # Not needed from 8.0.21 # # Group Replication configuration # plugin_load_add='group_replication.so' group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=off group_replication_local_address= "s3:33061" group_replication_group_seeds= "s1:33061,s2:33061,s3:33061" group_replication_bootstrap_group= off -
启动服务器并连接到它。创建用于分布式恢复的复制用户。
SET SQL_LOG_BIN=0; CREATE USER rpl_user@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%'; GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%'; GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%'; FLUSH PRIVILEGES; SET SQL_LOG_BIN=1;如果您使用
CHANGE REPLICATION SOURCE TO|提供用户凭据CHANGE MASTER TO声明，之后发布以下声明：CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery'; Or from MySQL 8.0.23: CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' \\ FOR CHANNEL 'group_replication_recovery'; -
如有必要，安装组复制插件。
INSTALL PLUGIN group_replication SONAME 'group_replication.so'; -
启动组复制。
mysql> START GROUP_REPLICATION;或者，如果您在语句上提供用于分布式恢复的用户凭据
START GROUP_REPLICATION（可以从 MySQL 8.0.21 开始）：mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
此时服务器 s3 已启动并运行，已加入组并赶上组中的其他服务器。再次查阅该 performance_schema.replication_group_members 表证实情况确实如此。
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 | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE | PRIMARY | 8.0.27 | XCom |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | s3 | 3306 | ONLINE | SECONDARY | 8.0.27 | XCom |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE | SECONDARY | 8.0.27 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
在服务器 s2 或服务器 s1 上发出相同的查询会产生相同的结果。此外，您还可以验证服务器 s3 是否已跟上：
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: 8.0.36-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 |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
