20.1.5 Group Replication 插件架构
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-plugin-architecture.html
MySQL Group Replication 是一个 MySQL 插件，它建立在现有的 MySQL 复制基础设施之上，利用二进制日志、基于行的日志记录和全局事务标识符等功能。它与当前的 MySQL 框架集成，如性能模式或插件和服务基础设施。以下图表展示了 MySQL Group Replication 的整体架构。
图 20.6 Group Replication 插件块图
MySQL Group Replication 插件包括一组用于捕获、应用和生命周期的 API，控制插件与 MySQL 服务器的交互方式。有接口使信息从服务器流向插件，反之亦然。这些接口将 MySQL 服务器核心与 Group Replication 插件隔离开来，主要是放置在事务执行管道中的钩子。在一个方向上，从服务器到插件，有关于事件的通知，如服务器启动、服务器恢复、服务器准备好接受连接以及服务器即将提交事务。在另一个方向上，插件指示服务器执行动作，如提交或中止正在进行的事务，或将事务排队到中继日志中。
Group Replication 插件架构的下一层是一组组件，当通知路由到它们时会做出反应。捕获组件负责跟踪正在执行的事务相关的上下文。应用程序组件负责在数据库上执行远程事务。恢复组件管理分布式恢复，并负责通过选择捐赠者、管理赶上过程和对捐赠者故障做出反应，使加入组的服务器保持最新。
沿着堆栈继续，复制协议模块包含复制协议的具体逻辑。它处理冲突检测，并接收和传播事务到组中。
Group Replication 插件架构的最后两层是 Group Communication System（GCS）API 和基于 Paxos 的群组通信引擎（XCom）的实现。GCS API 是一个高级 API，抽象出构建复制状态机所需的属性（参见第 20.1 节，“Group Replication 背景”）。因此，它将消息传递层的实现与插件的其余上层分离开来。群组通信引擎处理与复制组成员的通信。
20.2 开始
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-getting-started.html
20.2.1 在单主模式下部署群组复制
20.2.2 本地部署群组复制
MySQL Group Replication 是作为 MySQL 服务器的插件提供的；组中的每个服务器都需要配置和安装插件。本节提供了一个详细的教程，介绍了创建至少三个成员的复制组所需的步骤。
提示
要部署多个 MySQL 实例，您可以使用 InnoDB 集群，它使您能够轻松管理一组 MySQL 服务器实例在 MySQL Shell 中。InnoDB 集群将 MySQL Group Replication 封装在一个编程环境中，使您能够轻松部署一组 MySQL 实例以实现高可用性。此外，InnoDB 集群与 MySQL Router 无缝接口，使您的应用程序能够连接到集群而无需编写自己的故障转移过程。然而，对于不需要高可用性的类似用例，您可以使用 InnoDB ReplicaSet。有关 MySQL Shell 的安装说明，请参阅这里。
20.2.1 在单主模式下部署组复制
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-deploying-in-single-primary-mode.html
20.2.1.1 部署用于组复制的实例
20.2.1.2 配置用于组复制的实例
20.2.1.3 分布式恢复的用户凭据
20.2.1.4 启动组复制
20.2.1.5 引导组
20.2.1.6 将实例添加到组中
组中的每个 MySQL 服务器实例可以运行在独立的物理主机上，这是部署组复制的推荐方式。本节解释了如何创建一个由三个 MySQL Server 实例组成的复制组，每个实例运行在不同的主机上。有关在同一主机上部署运行组复制的多个 MySQL 服务器实例的信息，请参见第 20.2.2 节，“在本地部署组复制”，例如用于测试目的。
图 20.7 组架构
本教程解释了如何获取并部署带有组复制插件的 MySQL Server，如何在创建组之前配置每个服务器实例，以及如何使用性能模式监视来验证一切是否正常运行。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-deploying-instances.html
20.2.1.1 部署用于组复制的实例
第一步是部署至少三个 MySQL Server 实例，此过程演示了在多个主机上使用实例的方法，命名为 s1、s2 和 s3。假设每个主机上都安装了 MySQL Server（参见 Chapter 2, Installing MySQL）。MySQL Server 8.0 提供了 Group Replication 插件；不需要额外的软件，但插件必须安装在运行中的 MySQL 服务器上。请参见 Section 20.2.1.1, “Deploying Instances for Group Replication”；更多信息，请参见 Section 7.6, “MySQL Server Plugins”。
在这个示例中，使用了三个实例来组成一个组，这是创建组的最小实例数。增加更多实例可以增加组的容错能力。例如，如果组由三个成员组成，在一个实例故障的情况下，组可以继续运行。但在另一个实例故障的情况下，组将无法继续处理写事务。通过增加更多实例，组在继续处理事务的同时可以容忍更多服务器的故障。可以在一个组中使用的最大实例数为九。更多信息请参见 Section 20.1.4.2, “Failure Detection”。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
20.2.1.2 为 Group Replication 配置实例
本节解释了要为用于 Group Replication 的 MySQL Server 实例配置的配置设置。有关背景信息，请参阅 Section 20.3, “Requirements and Limitations”。
- 存储引擎
- 复制框架
- Group Replication 设置
存储引擎
对于 Group Replication，数据必须存储在 InnoDB 事务性存储引擎中（详情请参阅 Section 20.3.1, “Group Replication Requirements”）。使用其他存储引擎，包括临时的 MEMORY 存储引擎，可能会导致 Group Replication 中的错误。请设置 disabled_storage_engines 系统变量如下以防止其使用：
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
请注意，当禁用 MyISAM 存储引擎时，当您将 MySQL 实例升级到仍在使用 mysql_upgrade 的版本（在 MySQL 8.0.16 之前），mysql_upgrade 可能会失败并显示错误。为了处理这个问题，您可以在运行 mysql_upgrade 时重新启用该存储引擎，然后在重新启动服务器时再次禁用它。更多信息，请参阅 Section 6.4.5, “mysql_upgrade — Check and Upgrade MySQL Tables”。
复制框架
以下设置根据 MySQL Group Replication 的要求配置复制。
server_id=1 gtid_mode=ON enforce_gtid_consistency=ON
这些设置配置服务器使用唯一标识号 1，启用 Section 19.1.3, “Replication with Global Transaction Identifiers”，并且只允许执行可以安全记录使用 GTID 的语句。
在 MySQL 8.0.20 及更早版本中，还需要以下设置：
binlog_checksum=NONE
此设置禁用写入二进制日志的事件的校验和，默认情况下为启用状态。从 MySQL 8.0.21 开始，组复制支持二进制日志中的校验和，并可以使用它们来验证某些通道上事件的完整性，因此您可以使用默认设置。有关更多详细信息，请参见第 20.3.2 节，“组复制限制”。
如果您使用的是早于 8.0.3 的 MySQL 版本，在该版本中改进了复制的默认值，您还需要将这些行添加到成员的选项文件中。如果在后续版本的选项文件中有这些系统变量之一，请确保它们设置如下所示。有关更多详细信息，请参见第 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 的一部分，当来自客户端的事务被组成员接收，并且由组成员内部生成的视图更改事件被写入二进制日志时使用。 - 将
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 客户端连接的主机名可以在性能模式表replication_group_members的Member_host列中验证。如果多个组成员外部化了操作系统设置的默认主机名，加入成员可能无法将其解析为正确的成员地址，无法连接进行分布式恢复。在这种情况下，您可以使用 MySQL 服务器的report_host系统变量为每个服务器配置一个唯一的主机名来外部化。 - 配置
group_replication_group_seeds设置了组成员的主机名和端口，新成员使用这些信息来建立与组的连接。这些成员被称为种子成员。一旦连接建立，组成员信息将列在性能模式表replication_group_members中。通常group_replication_group_seeds列表包含每个组成员的group_replication_local_address的hostname:port，但这并非强制，可以选择一部分组成员作为种子。
重要
在group_replication_group_seeds中列出的hostname:port是种子成员的内部网络地址，由group_replication_local_address配置，而不是用于 SQL 客户端连接的hostname:port，例如在性能模式表replication_group_members中显示。
启动组的服务器不使用此选项，因为它是初始服务器，负责引导组。换句话说，启动组的服务器上存在的任何数据都将用作下一个加入成员的数据。第二个加入的服务器请求组内唯一的成员加入，第二个服务器上缺失的数据将从引导成员的捐赠数据中复制，然后组扩展。第三个加入的服务器可以请求其中任何两个加入，数据将同步到新成员，然后组再次扩展。后续服务器加入时重复此过程。
警告
当同时加入多个服务器时，请确保它们指向已经在组内的种子成员。不要使用正在加入组的成员作为种子，因为当联系时它们可能尚未加入组。
最好的做法是首先启动引导成员，并让它创建组。然后将其设置为其余加入成员的种子成员。这样确保在加入其余成员时已经形成了一个组。
不支持同时创建组并加入多个成员。这样做可能会成功，但有可能操作竞争，然后加入组的操作最终会出现错误或超时。
加入成员必须使用种子成员在group_replication_group_seeds选项中广告的相同协议（IPv4 或 IPv6）与种子成员通信。为了 Group Replication 的 IP 地址权限，种子成员的允许列表必须包含加入成员的 IP 地址，以供种子成员提供的协议使用，或者解析为该协议的地址的主机名。如果加入成员的协议与种子成员广告的协议不匹配，则必须设置并允许此地址或主机名，以及加入成员的group_replication_local_address。如果加入成员没有适当协议的允许地址，则其连接尝试将被拒绝。有关更多信息，请参见 Section 20.6.4, “Group Replication IP Address Permissions”。 - 配置
group_replication_bootstrap_group指示插件是否引导组。在这种情况下，即使s1是组的第一个成员，我们在选项文件中将此变量设置为关闭。相反，我们在实例运行时配置group_replication_bootstrap_group，以确保只有一个成员实际引导组。
重要group_replication_bootstrap_group变量必须在任何时候仅在属于组的一个服务器实例上启用，通常是您引导组的第一次（或者整个组被关闭并重新启动的情况下）。如果多次引导组，例如当多个服务器实例设置了此选项时，则可能会创建人为的脑裂情况，即存在具有相同名称的两个不同组。始终在第一个服务器实例上线后设置group_replication_bootstrap_group=off。
本教程中描述的系统变量是启动新成员所需的配置设置，但还有其他系统变量可用于配置组成员。这些列在 Section 20.9, “Group Replication Variables”中。
重要
一些系统变量，有些是特定于组复制，有些不是，都是组范围的配置设置，必须在所有组成员上具有相同的值。如果组成员为其中一个这些系统变量设置了值，并且加入的成员为其设置了不同的值，则加入的成员无法加入组，并返回错误消息。如果组成员为此系统变量设置了值，而加入的成员不支持该系统变量，则无法加入组。所有这些系统变量都在第 20.9 节，“组复制变量”中标识。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-user-credentials.html
20.2.1.3 分布式恢复的用户凭据
组复制使用分布式恢复过程在加入组时同步组成员。分布式恢复涉及将捐赠者的二进制日志中的事务传输到加入成员，使用名为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，确保如果涉及的服务器之一被置于脱机模式，则不会终止 Group Replication 连接。BACKUP_ADMIN，如果复制组中的服务器已设置为支持克隆（参见 Section 20.5.4.2, “Cloning for Distributed Recovery”）。此权限在分布式恢复的克隆操作中，需要成员作为捐赠者时才需要。GROUP_REPLICATION_STREAM，如果 MySQL 通信堆栈用于复制组（参见 Section 20.6.1, “Communication Stack for Connection Security Management”）。此权限要求用户帐户能够使用 MySQL 通信堆栈建立和维护 Group Replication 的连接。
- 在此示例中显示了用户*
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 时应用，包括如果group_replication_start_on_boot系统变量设置为ON时的自动启动。 - 在
START GROUP_REPLICATION中指定的用户凭据仅保存在内存中，并且通过STOP GROUP_REPLICATION语句或服务器关闭时会被删除。您必须发出START GROUP_REPLICATION语句再次提供凭据，因此不能使用这些凭据自动启动 Group Replication。通过指定用户凭据的这种方法有助于保护 Group Replication 服务器免受未经授权的访问。
- 有关使用每种提供用户凭据方法的安全影响的更多信息，请参阅 Section 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';
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-launching.html
20.2.1.4 启动 Group Replication
首先需要确保在服务器 s1 上安装了 Group Replication 插件。如果在选项文件中使用了 plugin_load_add='group_replication.so'，那么 Group Replication 插件已经安装好了，您可以继续下一步操作。否则，您必须手动安装该插件；要做到这一点，使用 mysql 客户端连接到服务器，并执行这里显示的 SQL 语句：
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
重要提示
在加载 Group Replication 之前，mysql.session 用户必须存在。mysql.session 是在 MySQL 版本 8.0.2 中添加的。如果您的数据字典是使用早期版本初始化的，则必须执行 MySQL 升级过程（参见 第三章，升级 MySQL）。如果未运行升级，则 Group Replication 在启动时会出现错误消息，指出尝试使用用户 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 | +----------------------------+----------+--------------------+----------------------+-------------+
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-bootstrap.html
20.2.1.5 引导组
首次启动组的过程称为引导。您使用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状态，并在端口3306上的s1上监听客户端连接。
用于演示服务器确实处于组中并且能够处理负载的目的，创建一个表并向其中添加一些内容。
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 语句已写入二进制日志。此外，数据已插入到表中并写入二进制日志，因此可以通过从捐赠者的二进制日志进行状态传输来用于分布式恢复。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html
20.2.1.6 向组中添加实例
此时，组中有一个成员，服务器 s1，其中包含一些数据。现在是扩展组的时候了，通过添加之前配置的其他两台服务器。
20.2.1.6.1 添加第二个实例
要添加第二个实例，服务器 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。如果在配置用户凭据时未启用二进制日志记录，并且不使用远程克隆操作进行状态传输，则必须在 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，并且在启动 Group Replication 之前不需要发出SET GLOBAL group_replication_bootstrap_group=ON;，因为组已经由服务器 s1 创建和引导。此时，服务器 s2 只需要添加到已经存在的组中。
提示
当 Group Replication 成功启动并且服务器加入组时，它会检查 super_read_only 变量。通过在成员的配置文件中将 super_read_only 设置为 ON，您可以确保由于任何原因在启动 Group Replication 时失败的服务器不接受事务。如果服务器应该作为读写实例加入组，例如作为单主组中的主服务器或作为多主组的成员，当 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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
MySQL8 中文参考（八十一）（2）https://developer.aliyun.com/article/1566073
