MySQL8 中文参考（八十一）（2）https://developer.aliyun.com/article/1566073
20.4 监视组复制
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html
20.4.1 GTIDs 和组复制
20.4.2 组复制服务器状态
20.4.3 复制组成员表
20.4.4 复制组成员统计表
您可以使用 MySQL 性能模式 监视组复制。这些性能模式表显示特定于组复制的信息：
replication_group_member_stats：参见 第 20.4.4 节，“复制组成员统计表”。replication_group_members：参见 第 20.4.3 节，“复制组成员表”。replication_group_communication_information：参见 第 29.12.11.15 节，“复制组通信信息表”。
这些性能模式复制表还显示与组复制相关的信息：
replication_connection_status显示有关组复制的信息，例如从组接收的事务以及在应用程序队列（中继日志）中排队的事务。replication_applier_status显示与组复制相关的通道和线程的状态。这些也可以用于监视各个工作线程正在做什么。
组复制插件创建的复制通道在此处列出：
group_replication_recovery: 用于与分布式恢复相关的复制更改。group_replication_applier: 用于来自组的传入更改，以应用直接来自组的事务。
有关影响组复制的系统变量的信息，请参见第 20.9.1 节，“组复制系统变量”。有关提供有关组复制信息的状态变量的信息，请参见第 20.9.2 节，“组复制状态变量”。
从 MySQL 8.0.21 开始，与组复制生命周期事件相关的消息（除错误外）被分类为系统消息；这些消息始终写入复制组成员的错误日志。您可以使用此信息来查看给定服务器在复制组中的成员资格历史。（以前，这些事件被分类为信息消息；对于 MySQL 服务器的版本早于 8.0.21 的情况，可以通过将log_error_verbosity设置为3将其添加到错误日志中。）
影响整个组的一些生命周期事件会在每个组成员上记录，例如新成员进入ONLINE状态或进行主要选举。其他事件仅在事件发生的成员上记录，例如在成员上启用或禁用超级只读模式，或成员离开组。如果发生频繁，一些可能指示问题的生命周期事件将记录为警告消息，包括成员变得无法访问然后再次可访问，以及成员通过从二进制日志进行状态传输或通过远程克隆操作开始分布式恢复。
注意
如果您正在使用mysqladmin监视一个或多个辅助实例，您应该知道，此实用程序执行的FLUSH STATUS语句会在本地实例上创建一个 GTID 事件，这可能会影响未来的组操作。
20.4.1 GTIDs 和组复制
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-gtids.html
组复制使用 GTIDs（全局事务标识符）来精确跟踪每个服务器实例上已提交的事务。所有组成员都需要设置gtid_mode=ON和enforce_gtid_consistency=ON。从客户端接收的事务由接收它们的组成员分配一个 GTID。从组外部源服务器通过异步复制通道接收到的任何复制事务在到达组成员时保留它们的 GTID。
从客户端接收的事务分配的 GTID 使用group_replication_group_name系统变量指定的组名作为标识符的 UUID 部分，而不是接收事务的单个组成员的服务器 UUID。因此，所有直接由组接收的事务都可以被识别并分组在 GTID 集合中，不管最初接收它们的成员是谁。每个组成员都有一块连续的 GTID 保留供其使用，当这些 GTID 被消耗完时，它会保留更多。group_replication_gtid_assignment_block_size系统变量设置了块的大小，默认情况下每个块中有 100 万个 GTID。
当新成员加入时，由组自动生成的视图更改事件（View_change_log_event）在二进制日志中记录时被赋予 GTID。默认情况下，这些事件的 GTID 也使用group_replication_group_name系统变量指定的组名作为标识符的 UUID 部分。从 MySQL 8.0.26 开始，您可以设置 Group Replication 系统变量group_replication_view_change_uuid以在视图更改事件的 GTID 中使用替代 UUID，以便它们易于与从客户端接收的事务区分开来。如果您的设置允许在组之间进行故障切换，并且您需要识别和丢弃特定于备份组的事务，则这可能很有用。替代 UUID 必须与成员的服务器 UUID 不同。它还必须与使用CHANGE REPLICATION SOURCE TO语句的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS选项应用于匿名事务的 GTID 中的任何 UUID 不同。
从 MySQL 8.0.27 开始，设置 GTID_ONLY=1、REQUIRE_ROW_FORMAT = 1 和 SOURCE_AUTO_POSITION = 1 适用于 Group Replication 通道 group_replication_applier 和 group_replication_recovery。这些设置在创建 Group Replication 通道时自动设置，或者当复制组中的成员服务器升级到 8.0.27 或更高版本时自动设置。通常使用 CHANGE REPLICATION SOURCE TO 语句设置这些选项，但请注意，您无法为 Group Replication 通道禁用它们。设置了这些选项后，组成员不会在这些通道的复制元数据存储库中持久保存文件名和文件位置。在必要时，GTID 自动定位和 GTID 自动跳过用于定位正确的接收器和应用程序位置。
额外事务
如果加入成员的 GTID 集中存在在组中现有成员中不存在的事务，则不允许完成分布式恢复过程，并且无法加入该组。如果进行了远程克隆操作，则这些事务将被删除和丢失，因为加入成员的数据目录被擦除。如果从捐赠者的二进制日志进行状态传输，则这些事务可能与组的事务发生冲突。
如果在 Group Replication 停止时在实例上执行管理事务，则可能会存在额外的事务。为了避免以这种方式引入新事务，请在发出管理语句之前始终将 sql_log_bin 系统变量的值设置为 OFF，然后在之后设置回 ON：
SET SQL_LOG_BIN=0; <administrator action> SET SQL_LOG_BIN=1;
将此系统变量设置为 OFF 意味着从那一点开始发生的事务不会写入二进制日志，并且不会分配 GTID。
如果加入成员存在额外的事务，请检查受影响服务器的二进制日志，查看额外事务的实际内容。将加入成员的数据和 GTID 集与当前组中的成员进行协调的最安全方法是使用 MySQL 的克隆功能，将内容从组中的一个服务器传输到受影响的服务器。有关如何执行此操作的说明，请参见 Section 7.6.7.3, “克隆远程数据”。如果需要该事务，请在成员成功重新加入后重新运行它。
20.4.2 Group Replication Server States
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html
Group Replication 群组成员的状态显示其在群组中的当前角色。Performance Schema 表replication_group_members显示了群组中每个成员的状态。如果群组完全正常运行且所有成员正常通信，则所有成员对所有其他成员报告相同的状态。但是，已离开群组或处于网络分区的成员无法准确报告其他服务器的信息。在这种情况下，该成员不会尝试猜测其他服务器的状态，而是将它们报告为不可访问。
一个群组成员可以处于以下状态：
ONLINE
服务器是群组的活跃成员，并处于完全运行状态。其他群组成员可以连接到它，客户端（如果适用）也可以连接到它。只有当成员处于ONLINE状态时，它才会与群组完全同步，并参与其中。
RECOVERING
服务器已加入一个群组，并正在成为活跃成员的过程中。当前正在进行分布式恢复，成员正在接收来自捐赠者的状态传输，使用远程克隆操作或捐赠者的二进制日志。此状态为
更多信息，请参见 Section 20.5.4, “Distributed Recovery”。
OFFLINE
Group Replication 插件已加载，但成员不属于任何群组。在成员加入或重新加入群组时，可能会暂时出现此状态。
ERROR
该成员处于错误状态，并且作为群组成员无法正常运行。成员可能在应用事务期间或恢复阶段进入错误状态。处于此状态的成员不参与群组的事务。有关错误状态可能原因的更多信息，请参见 Section 20.7.7, “Responses to Failure Detection and Network Partitioning”。
根据group_replication_exit_state_action设置的退出操作，成员处于只读模式（super_read_only=ON），也可能处于离线模式（offline_mode=ON）。请注意，遵循OFFLINE_MODE退出操作的离线模式服务器显示为ERROR状态，而不是OFFLINE。采用ABORT_SERVER退出操作的服务器将关闭并从组的视图中移除。更多信息，请参见 Section 20.7.7.4, “退出操作”。
当成员加入或重新加入复制组时，在组完成兼容性检查并接受其为成员之前，其状态可能显示为ERROR。
UNREACHABLE
本地故障检测器怀疑无法联系到成员，因为组的消息超时。这可能发生在成员非自愿断开连接的情况下。如果您在其他服务器看到此状态，也可能意味着您查询此表的成员是分区的一部分，组的一部分服务器可以相互联系，但无法联系组中的其他服务器。更多信息，请参见 Section 20.7.8, “处理网络分区和失去法定人数”。
请参见 Section 20.4.3, “复制组成员表”，了解性能模式表内容的示例。
20.4.3 The replication_group_members Table
dev.mysql.com/doc/refman/8.0/en/group-replication-replication-group-members.html
performance_schema.replication_group_members表用于监视组成员的不同服务器实例的状态。表中的信息在视图更改时更新，例如当新成员加入时动态更改组配置时。在那时，服务器交换一些元数据以同步自己并继续共同合作。信息在所有作为复制组成员的服务器实例之间共享，因此可以从任何成员查询所有组成员的信息。该表可用于获取复制组状态的高级视图，例如通过发出：
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 | d391e9ee-2691-11ec-bf61-00059a3c7a00 | example1 | 4410 | ONLINE | PRIMARY | 8.0.27 | XCom | | group_replication_applier | e059ce5c-2691-11ec-8632-00059a3c7a00 | example2 | 4420 | ONLINE | SECONDARY | 8.0.27 | XCom | | group_replication_applier | ecd9ad06-2691-11ec-91c7-00059a3c7a00 | example3 | 4430 | ONLINE | SECONDARY | 8.0.27 | XCom | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.0007 sec)
根据这个结果，我们可以看到该组由三个成员组成。表中显示了每个成员的server_uuid，以及成员的主机名和端口号，客户端用于连接的信息。MEMBER_STATE列显示了第 20.4.2 节，“组复制服务器状态”中的一个状态，在这种情况下显示该组的所有三个成员都是ONLINE，MEMBER_ROLE列显示有两个从属节点和一个主节点。因此，该组必须在单主模式下运行。MEMBER_VERSION列在升级组并合并运行不同 MySQL 版本的成员时可能会有用。MEMBER_COMMUNICATION_STACK列显示了组使用的通信堆栈。
关于MEMBER_HOST值及其对分布式恢复过程的影响的更多信息，请参见第 20.2.1.3 节，“用于分布式恢复的用户凭据”。
20.4.4 The replication_group_member_stats Table
译文：
dev.mysql.com/doc/refman/8.0/en/group-replication-replication-group-member-stats.html
每个复制组中的成员都会对组接收的事务进行认证和应用。关于认证者和应用者过程的统计信息对于了解应用程序队列的增长情况、发现了多少冲突、检查了多少事务、哪些事务在所有地方都已提交等方面非常有用。
performance_schema.replication_group_member_stats 表提供了与认证过程相关的组级信息，以及每个复制组成员接收和发起的事务的统计信息。这些信息在所有作为复制组成员的服务器实例之间共享，因此可以从任何成员查询所有组成员的信息。请注意，远程成员的统计信息刷新由group_replication_flow_control_period 选项中指定的消息周期控制，因此这些统计信息可能与在进行查询的成员本地收集的统计信息略有不同。要使用此表监视 Group Replication 成员，请执行以下语句：
mysql> SELECT * FROM performance_schema.replication_group_member_stats\G
从 MySQL 8.0.19 开始，您还可以使用以下语句：
mysql> TABLE performance_schema.replication_group_member_stats\G
这些列对于监视组中连接的成员的性能非常重要。假设组中的一个成员总是报告其队列中的事务数量比其他成员多。这意味着该成员延迟了，并且无法跟上组中其他成员的步伐。根据这些信息，您可以决定是将该成员从组中移除，还是延迟其他组成员的事务处理，以减少排队事务的数量。这些信息还可以帮助您决定如何调整 Group Replication 插件的流量控制，请参阅 Section 20.7.2, “Flow Control”。
20.5 群组复制操作
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-operations.html
20.5.1 配置在线群组
20.5.2 重新启动一个群组
20.5.3 事务一致性保证
20.5.4 分布式恢复
20.5.5 支持 IPv6 和混合 IPv6 和 IPv4 群组
20.5.6 使用 MySQL 企业备份与群组复制
本节解释了管理群组的常见操作。
20.5.1 配置在线组
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-online-group.html
20.5.1.1 更改主服务器
20.5.1.2 改变组模式
20.5.1.3 使用 Group Replication 组写一致性
20.5.1.4 设置组的通信协议版本
20.5.1.5 配置成员操作
您可以在 Group Replication 运行时使用一组函数配置在线组，这些函数依赖于组操作协调员。这些函数由 Group Replication 插件在 8.0.13 及更高版本中安装。本节描述了如何对运行中的组进行更改以及可用的功能。
重要提示
协调员要能够在运行中的组上配置组范围的操作，所有成员必须运行 MySQL 8.0.13 或更高版本，并安装了这些功能。
要使用这些功能，请连接到运行中的组的成员，并使用SELECT语句调用该函数。 Group Replication 插件处理操作及其参数，协调员将其发送给所有对调用函数的成员可见的成员。如果操作被接受，所有成员执行该操作并在完成后发送终止消息。一旦所有成员声明操作已完成，调用成员将结果返回给客户端。
在配置整个组时，操作的分布性意味着它们与 Group Replication 插件的许多进程进行交互，因此您应该遵守以下规定：
您可以在任何地方发出配置操作。 如果要将成员 A 设置为新的主服务器，则无需在成员 A 上调用操作。所有操作都以协调的方式发送并在所有组成员上执行。此外，操作的分布式执行具有不同的影响：如果发出操作的成员死亡，则任何已经运行的配置过程将继续在其他成员上运行。在发出操作的成员死亡的极少情况下，您仍然可以使用监控功能确保其他成员成功完成操作。
所有成员必须在线。 为了简化迁移或选举过程并确保它们尽可能快速，组不得包含当前处于分布式恢复过程中的任何成员，否则配置操作将被发出语句的成员拒绝。
在配置更改期间，没有成员可以加入组。 任何尝试在协调的配置更改期间加入组的成员都会离开组并取消其加入过程。
一次只能进行一个配置更改。 正在执行配置更改的组不能接受任何其他组的配置更改，因为并发的配置操作可能导致成员分歧。
所有成员必须运行 MySQL 8.0.13 或更高版本。 由于配置操作的分布式特性，所有成员必须识别它们才能执行它们。如果任何运行 MySQL Server 版本低于 8.0.12 的服务器存在于组中，则操作将被拒绝。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-change-primary.html
20.5.1.1 更改主节点
本节解释了如何更改单一主节点组中的主节点，使用group_replication_set_as_primary()函数，该函数可以在组的任何成员上运行。执行此操作后，当前主节点将成为只读辅助节点，指定的组成员将成为读写主节点；这取代了第 20.1.3.1 节，“单一主节点模式”中描述的通常的主节点选举过程。
如果标准的源到副本复制通道正在现有的主节点上运行，除了组复制通道之外，您必须在更改主节点之前停止该复制通道。您可以使用性能模式表replication_group_members中的MEMBER_ROLE列，或者group_replication_primary_member状态变量来识别当前的主节点。
如果所有成员未运行相同的 MySQL 服务器版本，则只能指定运行组中最低 MySQL 服务器版本的新主节点。此保护措施旨在确保组与新功能保持兼容。这适用于所有 MySQL 版本，并从 MySQL 8.0.17 开始强制执行。
组正在等待的任何未提交事务必须在操作完成之前提交、回滚或终止。在 MySQL 8.0.29 之前，该函数会等待现有主节点上的所有活动事务结束，包括在使用该函数后启动的传入事务。从 MySQL 8.0.29 开始，您可以为在使用该函数时正在运行的事务指定从 0 秒（立即）到 3600 秒（60 分钟）的超时时间。为使超时生效，组的所有成员必须运行 MySQL 8.0.29 或更高版本。超时没有默认设置，因此如果您不设置它，等待时间没有上限，新事务可以在此期间启动。
当超时到期时，对于尚未达到提交阶段的任何事务，客户端会被断开连接，以防事务继续进行。已达到提交阶段的事务将被允许完成。设置超时还会阻止从那时起在主服务器上启动新事务。即使它们不修改任何数据，显式定义的事务（使用START TRANSACTION或BEGIN语句）也会受到超时、断开连接和传入事务阻止的影响。为了允许在函数运行时检查主服务器，允许执行不修改数据的单个语句，如一致性规则下允许的查询中列出的语句。
通过发出以下语句，传递成员的server_uuid，该成员将成为组的新主要成员：
SELECT group_replication_set_as_primary(*member_uuid*);
在 MySQL 8.0.29 及更高版本中，您可以添加一个超时，如下所示：
SELECT group_replication_set_as_primary(‘00371d66-3c45-11ea-804b-080027337932’, 300)
要检查超时的状态，请使用性能模式threads表中的PROCESSLIST_INFO列，如下所示：
mysql> SELECT NAME, PROCESSLIST_INFO FROM performance_schema.threads -> WHERE NAME="thread/group_rpl/THD_transaction_monitor"\G *************************** 1\. row *************************** NAME: thread/group_rpl/THD_transaction_monitor PROCESSLIST_INFO: Group replication transaction monitor: Stopped client connections
状态显示了事务监控线程何时被创建，新事务何时被停止，带有未提交事务的客户端连接何时被断开，最后，进程何时完成并允许新事务再次进行。
在操作运行时，您可以通过发出以下语句来检查其进度：
mysql> SELECT event_name, work_completed, work_estimated -> FROM performance_schema.events_stages_current -> WHERE event_name LIKE "%stage/group_rpl%"\G *************************** 1\. row *************************** EVENT_NAME: stage/group_rpl/Primary Election: Waiting for members to turn on super_read_only WORK_COMPLETED: 3 WORK_ESTIMATED: 5
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-changing-group-mode.html
20.5.1.2 更改组模式
本节解释了如何更改组运行的模式，即单主或多主。用于更改组模式的函数可以在任何成员上运行。
切换到单主模式
使用group_replication_switch_to_single_primary_mode()函数通过执行以下命令将运行在多主模式下的组切换到单主模式：
SELECT group_replication_switch_to_single_primary_mode()
当您切换到单主模式时，所有组成员上也会禁用严格的一致性检查，这是单主模式所要求的（group_replication_enforce_update_everywhere_checks=OFF）。
如果没有传入字符串，在结果为单主组的新主要选举中，遵循 20.1.3.1 节，“单主模式”中描述的选举策略。要覆盖选举过程并在过程中配置多主组的特定成员作为新主要成员，请获取成员的server_uuid并将其传递给group_replication_switch_to_single_primary_mode()。例如，执行以下命令：
SELECT group_replication_switch_to_single_primary_mode(*member_uuid*);
如果在运行 MySQL Server 版本为 8.0.17 的成员上调用该函数，并且所有成员都运行 MySQL Server 版本为 8.0.17 或更高版本，则只能指定运行最低 MySQL Server 版本的新主要成员，基于补丁版本。这个保障是为了确保组保持与新功能的兼容性。如果不指定新的主要成员，选举过程将考虑组成员的补丁版本。
如果任何成员运行的 MySQL Server 版本介于 MySQL 8.0.13 和 MySQL 8.0.16 之间，则不会强制执行此保障，并且您可以指定任何新的主要成员，但建议选择运行组中最低 MySQL Server 版本的主要成员。如果不指定新的主要成员，选举过程仅考虑组成员的主要版本。
在操作运行时，您可以通过执行以下命令来检查其进度：
SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%"; +----------------------------------------------------------------------------+----------------+----------------+ | event_name | work_completed | work_estimated | +----------------------------------------------------------------------------+----------------+----------------+ | stage/group_rpl/Primary Switch: waiting for pending transactions to finish | 4 | 20 | +----------------------------------------------------------------------------+----------------+----------------+
切换到多主模式
使用group_replication_switch_to_multi_primary_mode()函数通过执行以下命令将运行在单主模式下的组切换到多主模式：
SELECT group_replication_switch_to_multi_primary_mode()
在执行一些协调的组操作以确保数据的安全性和一致性之后，所有属于该组的成员都变为主节点。
当您将在单主模式下运行的组更改为多主模式时，运行 MySQL 8.0.17 或更高版本的成员如果运行的 MySQL 服务器版本高于组中存在的最低版本，则会自动处于只读模式。运行 MySQL 8.0.16 或更低版本的成员不执行此检查，并始终处于读写模式。
当操作运行时，您可以通过发出以下命令来检查其进度：
SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%"; +----------------------------------------------------------------------+----------------+----------------+ | event_name | work_completed | work_estimated | +----------------------------------------------------------------------+----------------+----------------+ | stage/group_rpl/Multi-primary Switch: applying buffered transactions | 0 | 1 | +----------------------------------------------------------------------+----------------+----------------+
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-group-write-consensus.html
20.5.1.3 使用 Group Replication 群组写共识
本节介绍如何检查和配置群组在任何时候的最大共识实例数。这个最大值被称为群组的事件视界，是群组可以并行执行的最大共识实例数。这使您能够微调您的 Group Replication 部署的性能。例如，默认值为 10 适用于在局域网上运行的群组，但对于在较慢的网络（如广域网）上运行的群组，增加此数字以提高性能。
检查群组的写并发性
使用group_replication_get_write_concurrency()函数，在运行时检查群组的事件视界值，通过发出：
SELECT group_replication_get_write_concurrency();
配置群组的写并发性
使用group_replication_set_write_concurrency()函数，设置系统可以并行执行的最大共识实例数，通过发出：
SELECT group_replication_set_write_concurrency(*instances*);
其中*instances*是新的最大共识实例数。需要GROUP_REPLICATION_ADMIN权限才能使用此功能。
dev.mysql.com/doc/refman/8.0/en/group-replication-communication-protocol.html
20.5.1.4 设置组的通信协议版本
从 MySQL 8.0.16 开始，Group Replication 具有组的通信协议的概念。Group Replication 通信协议版本可以被明确管理，并设置为适应您希望组支持的最旧 MySQL Server 版本。这使得可以从不同 MySQL Server 版本的成员组成组，同时确保向后兼容性。
- MySQL 5.7.14 版本允许消息的压缩（参见 Section 20.7.4, “Message Compression”）。
- MySQL 8.0.16 版本还允许消息的分段（参见 Section 20.7.5, “Message Fragmentation”）。
- MySQL 8.0.27 版本还允许在单主模式下，当
group_replication_paxos_single_leader设置为 true 时，组通信引擎可以与单一一致性领导者一起运行（参见 Section 20.7.3, “Single Consensus Leader”）。
所有组成员必须使用相同的通信协议版本，以便组成员可以处于不同的 MySQL Server 版本，但只发送所有组成员都能理解的消息。
MySQL 服务器在版本 X 下，只有当复制组的通信协议版本小于或等于 X 时，才能加入并达到ONLINE状态。当新成员加入复制组时，它会检查现有成员所宣布的通信协议版本。如果加入成员支持该版本，则加入该组并使用组宣布的通信协议，即使该成员支持额外的通信能力。如果加入成员不支持通信协议版本，则会被从组中驱逐。
如果两个成员尝试在同一成员变更事件中加入，只有当两个成员的通信协议版本已经与组的通信协议版本兼容时，它们才能加入。与组不同通信协议版本的成员必须独立加入。例如：
- 一个 MySQL Server 8.0.16 实例可以成功加入使用通信协议版本 5.7.24 的组。
- 一个 MySQL Server 5.7.24 实例无法成功加入使用通信协议版本 8.0.16 的组。
- 两个 MySQL Server 8.0.16 实例不能同时加入使用通信协议版本 5.7.24 的组。
- 两个 MySQL Server 8.0.16 实例可以同时加入使用通信协议版本 8.0.16 的组。
您可以使用group_replication_get_communication_protocol()函数检查组正在使用的通信协议，该函数返回组支持的最旧 MySQL Server 版本。组的所有现有成员返回相同的通信协议版本。例如：
SELECT group_replication_get_communication_protocol(); +------------------------------------------------+ | group_replication_get_communication_protocol() | +------------------------------------------------+ | 8.0.16 | +------------------------------------------------+
请注意，group_replication_get_communication_protocol()函数返回组支持的最低 MySQL 版本，这可能与传递给group_replication_set_communication_protocol()函数的版本号不同，并且可能与您在使用该函数的成员上安装的 MySQL Server 版本不同。
如果您需要更改组的通信协议版本，以便早期版本的成员可以加入，请使用group_replication_set_communication_protocol()函数指定您希望允许的最旧成员的 MySQL Server 版本。如果可能的话，这将使组回退到兼容的通信协议版本。使用此函数需要GROUP_REPLICATION_ADMIN权限，并且在发出语句时，所有现有组成员必须在线，没有多数成员丢失。例如：
SELECT group_replication_set_communication_protocol("5.7.25");
如果您将复制组的所有成员升级到新的 MySQL Server 版本，则组的通信协议版本不会自动升级以匹配。如果您不再需要支持早期版本的成员，您可以使用group_replication_set_communication_protocol()函数将通信协议版本设置为您已经升级成员的新 MySQL Server 版本。例如：
SELECT group_replication_set_communication_protocol("8.0.16");
group_replication_set_communication_protocol() 函数被实现为一个组操作，因此在组的所有成员上同时执行。组操作开始缓冲消息，并等待任何正在进行中的传出消息的传递完成，然后更改通信协议版本并发送缓冲消息。如果在更改通信协议版本后的任何时间点，有成员尝试加入组，组成员会宣布新的协议版本。
MySQL InnoDB 集群在使用 AdminAPI 操作更改集群拓扑结构时，自动透明地管理其成员的通信协议版本。InnoDB 集群始终使用当前所有实例支持的最新通信协议版本，这些实例当前是集群的一部分或正在加入其中。有关详细信息，请参阅 InnoDB 集群和组复制协议。
原文：
dev.mysql.com/doc/refman/8.0/en/group-replication-member-actions.html
20.5.1.5 配置成员操作
从 MySQL 8.0.26 开始，Group Replication 具有设置组成员在指定情况下采取的操作的能力。可以使用函数单独启用和禁用成员操作。服务器的成员操作配置在离开组后也可以重置为默认值。
管理员（具有GROUP_REPLICATION_ADMIN权限）可以使用group_replication_enable_member_action或group_replication_disable_member_action函数在组的主服务器上配置成员操作。然后，成员操作配置（包括所有成员操作以及它们是否启用或禁用）通过 Group Replication 的组消息传播到其他组成员和加入成员。因此，所有组成员都具有相同的成员操作配置。您还可以在不属于任何组的服务器上配置成员操作，只要安装了 Group Replication 插件。在这种情况下，成员操作配置不会传播到任何其他服务器。
如果在使用函数配置成员操作的服务器是组的一部分，则它必须是单主模式下的当前主服务器，并且必须是大多数的一部分。配置更改在 Group Replication 内部被跟踪，但不会被赋予 GTID，并且不会被写入二进制日志，因此不会传播到任何组外的服务器，如下游复制。每次启用或禁用成员操作时，Group Replication 都会增加其成员操作配置的版本号。
成员操作配置传播给成员的方式如下：
- 在启动组时，引导组的服务器的成员操作配置成为组的配置。
- 如果组的最低 MySQL Server 版本支持成员操作，则加入成员在加入时进行状态交换过程中接收组的成员操作配置。在这种情况下，加入成员将自己的成员操作配置替换为组的配置。
- 如果支持成员操作的加入成员加入一个最低 MySQL Server 版本不支持成员操作的组，则加入时不会接收成员操作配置。在这种情况下，加入成员将自己的配置重置为默认值。
不支持成员操作的成员无法加入具有成员操作配置的组，因为其 MySQL Server 版本低于现有组成员运行的最低版本。
Performance Schema 表replication_group_member_actions列出了配置中可用的成员操作、触发它们的事件以及它们当前是否启用。成员操作的优先级从 1 到 100，较低的值首先执行。如果在执行成员操作时发生错误，则可以记录成员操作的失败，但否则忽略。如果认为成员操作的失败是关键的，则可以根据group_replication_exit_state_action系统变量指定的策略进行处理。
可以使用 Performance Schema 表replication_group_configuration_version查看的mysql.replication_group_configuration_version表记录了成员操作配置的当前版本。每当使用函数启用或禁用成员操作时，版本号都会递增。
group_replication_reset_member_actions函数只能在不属于任何组的服务器上使用。它将成员操作配置重置为默认设置，并将其版本号重置为 1。服务器必须可写（使用read_only系统变量设置为OFF），并安装了 Group Replication 插件。您可以使用此函数删除服务器在成为组的一部分时使用的成员操作配置，如果您打算将其用作没有成员操作或具有不同成员操作的独立服务器。
成员操作：mysql_disable_super_read_only_if_primary
成员操作mysql_disable_super_read_only_if_primary可以配置为使单主模式下的组在选举新主时保持在超级只读模式，以便该组仅接受复制事务，不接受来自客户端的直接写入。这种设置意味着当一个组的目的是为另一个组提供灾难容忍的次要备份时，您可以确保次要组与第一个组保持同步。
默认情况下，当选为主服务器时，超级只读模式在主服务器上被禁用，以便主服务器变为读写，并接受来自复制源服务器和客户端的更新。这是当成员操作mysql_disable_super_read_only_if_primary被启用时的情况，这是其默认设置。如果您使用group_replication_disable_member_action函数将操作设置为禁用，主服务器在选举后仍然保持在超级只读模式。在这种状态下，它不接受来自任何客户端的更新，甚至是具有CONNECTION_ADMIN或SUPER权限的用户。它仍然会接受由复制线程执行的更新。
MySQL8 中文参考（八十一）（4）https://developer.aliyun.com/article/1566076
