MySQL8 中文参考（八十二）

ApacheCN_飞龙

发布于 2024-06-26 19:16:51

560

发布于 2024-06-26 19:16:51

文章被收录于专栏：信数据得永生信数据得永生

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

20.6 组复制安全性

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-security.html

20.6.1 用于连接安全管理的通信堆栈

20.6.2 使用安全套接字层（SSL）保护组通信连接

20.6.3 保护分布式恢复连接

20.6.4 组复制 IP 地址权限

本节解释了如何保护一个组，保护组成员之间的连接，或通过建立 IP 地址白名单来建立安全边界。

20.6.1 连接安全管理的通信堆栈

译文：dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html

从 MySQL 8.0.27 开始，Group Replication 可以通过以下方法之一保护成员之间的组通信连接：

使用其自身的安全协议实现，包括 TLS/SSL 和用于传入组通信系统（GCS）连接的白名单。这是 MySQL 8.0.26 及更早版本的唯一选项。
使用 MySQL 服务器自身的连接安全代替 Group Replication 的实现。使用 MySQL 协议意味着可以使用标准的用户认证方法来授予（或撤销）对组的访问权限，而不是使用白名单，并且服务器协议的最新功能始终在发布时可用。此选项从 MySQL 8.0.27 开始提供。

通过设置系统变量group_replication_communication_stack为XCOM来选择使用 Group Replication 的自身实现（这是默认选择），或者设置为MYSQL以使用 MySQL 服务器的连接安全。

复制组要使用 MySQL 通信堆栈，需要进行以下额外配置。当您从使用 XCom 通信堆栈切换到 MySQL 通信堆栈时，特别重要的是确保所有这些要求都得到满足。

MySQL 通信堆栈的 Group Replication 要求

由group_replication_local_address系统变量配置的网络地址必须设置为 MySQL 服务器正在侦听的 IP 地址和端口之一，如服务器的bind_address系统变量所指定的那样。每个成员的 IP 地址和端口组合在组内必须是唯一的。建议为每个组成员配置group_replication_group_seeds系统变量，其中包含所有组成员的本地地址。
MySQL 通信栈支持网络命名空间，而 XCom 通信栈不支持。如果使用网络命名空间与组复制的本地地址（group_replication_local_address）一起使用，必须为每个组成员使用CHANGE REPLICATION SOURCE TO语句进行配置。此外，每个组成员的report_host服务器系统变量必须设置为报告命名空间。所有组成员必须使用相同的命名空间，以避免在分布式恢复期间可能出现的地址解析问题。
group_replication_ssl_mode系统变量必须设置为组通信所需的设置。此系统变量控制组通信是否启用或禁用 TLS/SSL。对于 MySQL 8.0.26 及更早版本，TLS/SSL 配置始终从服务器的 SSL 设置中获取；对于 MySQL 8.0.27 及更高版本，在使用 MySQL 通信栈时，TLS/SSL 配置将从组复制的分布式恢复设置中获取。为避免潜在冲突，此设置应在所有组成员上相同。
--ssl或--skip-ssl服务器选项和require_secure_transport服务器系统变量的设置应在所有组成员上相同，以避免潜在冲突。如果group_replication_ssl_mode设置为REQUIRED、VERIFY_CA或VERIFY_IDENTITY，请使用--ssl和require_secure_transport=ON。如果group_replication_ssl_mode设置为DISABLED，请使用require_secure_transport=OFF。
如果为组通信启用了 TLS/SSL，则必须配置 Group Replication 的用于保护分布式恢复的设置，如果尚未配置，则必须配置，或者如果已经配置，则必须进行验证。MySQL 通信堆栈不仅在成员之间的分布式恢复连接中使用这些设置，还在一般组通信中使用 TLS/SSL 配置。group_replication_recovery_use_ssl和其他group_replication_recovery_*系统变量在第 20.6.3.2 节，“用于分布式恢复的安全套接字层（SSL）连接”中有解释。
当组使用 MySQL 通信堆栈时，不使用 Group Replication 白名单，因此group_replication_ip_allowlist和group_replication_ip_whitelist系统变量将被忽略，无需配置。
Group Replication 用于分布式恢复的复制用户帐户，如使用CHANGE REPLICATION SOURCE TO语句配置的，用于在设置 Group Replication 连接时由 MySQL 通信堆栈进行身份验证。这个用户帐户在所有组成员上都是相同的，必须具有以下权限：
- GROUP_REPLICATION_STREAM。此权限是用户帐户能够使用 MySQL 通信堆栈建立 Group Replication 连接所必需的。
- CONNECTION_ADMIN。此权限是为了确保 Group Replication 连接在涉及的服务器之一处于离线模式时不会被终止。如果使用 MySQL 通信堆栈而没有此权限，则被放置在离线模式的成员将被从组中驱逐。
这些权限是所有复制用户帐户必须具有的权限REPLICATION SLAVE和BACKUP_ADMIN的附加权限（请参阅第 20.2.1.3 节，“用于分布式恢复的用户凭据”）。在添加新权限时，请确保在发出GRANT语句之前通过发出SET SQL_LOG_BIN=0跳过每个组成员上的二进制日志记录，并在之后通过SET SQL_LOG_BIN=1，以便本地事务不会干扰 Group Replication 的重新启动。

group_replication_communication_stack实际上是一个群组范围的配置设置，所有群组成员必须设置相同的值。然而，Group Replication 自身并不检查群组范围配置设置的一致性。一个值与其他群组成员不同的成员无法与其他成员通信，因为通信协议不兼容，所以无法交换关于其配置设置的信息。

这意味着虽然在 Group Replication 运行时可以更改系统变量的值，并在重新启动群组成员上的 Group Replication 后生效，但成员仍然无法重新加入群组，直到所有成员的设置都已更改。因此，您必须在所有成员上停止 Group Replication 并更改系统变量的值，然后才能重新启动群组。因为所有成员都已停止，所以需要通过一个具有group_replication_bootstrap_group=ON的服务器进行完整重启群组（引导）。在值更改生效之前，您可以在停止的群组成员上进行其他必要的设置更改。

对于一个运行中的群组，按照以下步骤更改group_replication_communication_stack的值和其他必要的设置，以将一个群组从 XCom 通信栈迁移到 MySQL 通信栈，或者从 MySQL 通信栈迁移到 XCom 通信栈：

在每个群组成员上停止 Group Replication，使用STOP GROUP_REPLICATION语句。最后停止主要成员，以免触发新的主要选举并等待其完成。

在每个群组成员上，将系统变量group_replication_communication_stack设置为新的通信栈，MYSQL或XCOM，具体取决于情况。您可以通过编辑 MySQL 服务器配置文件（在 Linux 和 Unix 系统上通常命名为my.cnf，在 Windows 系统上为my.ini），或使用SET语句来完成。例如：

SET PERSIST group_replication_communication_stack="MYSQL";

如果您正在将复制组从 XCom 通信堆栈（默认）迁移到 MySQL 通信堆栈，请在每个组成员上配置或重新配置所需的系统变量为适当的设置，如上述清单中所述。例如，group_replication_local_address系统变量必须设置为 MySQL 服务器正在侦听的 IP 地址和端口之一。还要使用CHANGE REPLICATION SOURCE TO语句配置任何网络命名空间。

如果您正在将复制组从 XCom 通信堆栈（默认）迁移到 MySQL 通信堆栈，请在每个组成员上发出GRANT语句，以赋予复制用户帐户GROUP_REPLICATION_STREAM和CONNECTION_ADMIN权限。您需要将组成员从应用 Group Replication 停止时应用的只读状态中取出。还要确保在发出GRANT语句之前在每个组成员上跳过二进制日志记录，通过在发出语句之前执行SET SQL_LOG_BIN=0，并在之后执行SET SQL_LOG_BIN=1，以确保本地事务不会干扰重新启动 Group Replication。例如：

SET GLOBAL SUPER_READ_ONLY=OFF;
SET SQL_LOG_BIN=0; 
GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;

如果您正在将复制组从 MySQL 通信堆栈迁移回 XCom 通信堆栈，请在每个组成员上重新配置上述要求中的系统变量，以适合 XCom 通信堆栈的设置。第 20.9 节，“组复制变量”列出了系统变量及其默认值以及 XCom 通信堆栈的要求。

注意

XCom 通信堆栈不支持网络命名空间，因此组复制本地地址（group_replication_local_address系统变量）不能使用这些。通过发出CHANGE REPLICATION SOURCE TO语句取消设置。
当切换回 XCom 通信堆栈时，由group_replication_recovery_use_ssl和其他group_replication_recovery_*系统变量指定的设置不用于保护组通信。相反，组复制系统变量group_replication_ssl_mode用于激活 SSL 用于组通信连接并指定连接的安全模式，其余配置取自服务器的 SSL 配置。有关详细信息，请参见第 20.6.2 节“使用安全套接字层（SSL）保护组通信连接”。

要重新启动组，请按照第 20.5.2 节“重新启动组”中的过程进行操作，该节解释了如何安全地引导已执行和认证事务的组。由具有group_replication_bootstrap_group=ON的服务器引导是必要的，以更改通信堆栈，因为所有成员必须关闭。

成员现在使用新的通信堆栈相互连接。任何将group_replication_communication_stack设置为先前通信堆栈（或在 XCom 的情况下默认设置）的服务器将无法加入该组。重要的是要注意，由于组复制甚至无法看到加入尝试，因此它不会检查并用错误消息拒绝加入成员。相反，当先前的通信堆栈放弃尝试联系新的通信堆栈时，尝试加入会悄无声息地失败。

20.6.2 用安全套接字层（SSL）保护组通信连接

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-secure-socket-layer-support-ssl.html

安全套接字可以用于组内成员之间的组通信连接。

Group Replication 系统变量group_replication_ssl_mode用于激活 SSL 用于组通信连接并指定连接的安全模式。默认设置意味着不使用 SSL。该选项有以下可能的值：

表 20.1 group_replication_ssl_mode 配置值

值	描述
DISABLED	建立一个未加密的连接（默认设置）。
REQUIRED	如果服务器支持安全连接，请建立安全连接。
VERIFY_CA	类似于REQUIRED，但另外根据配置的证书颁发机构（CA）证书验证服务器 TLS 证书。
VERIFY_IDENTITY	类似于VERIFY_CA，但另外验证服务器证书是否与尝试连接的主机匹配。

如果使用 SSL，则配置安全连接的方式取决于是使用 XCom 还是 MySQL 通信堆栈进行组通信（自 MySQL 8.0.27 起可选择两者之间的一个）。

当使用 XCom 通信堆栈（group_replication_communication_stack=XCOM）时： Group Replication 的组通信连接的其余配置取自服务器的 SSL 配置。有关配置服务器 SSL 的选项的更多信息，请参阅加密连接的命令选项。应用于 Group Replication 组通信连接的服务器 SSL 选项如下：

表 20.2 SSL 选项

服务器配置	描述
ssl_key	SSL 私钥文件的路径名，格式为 PEM。在客户端端，这是客户端私钥。在服务器端，这是服务器私钥。
ssl_cert	SSL 公钥证书文件的路径名，格式为 PEM。在客户端端，这是客户端公钥证书。在服务器端，这是服务器公钥证书。
ssl_ca	证书颁发机构（CA）证书文件的路径名，格式为 PEM。
ssl_capath	包含受信任的 SSL 证书颁发机构（CA）证书文件的目录路径名，格式为 PEM。
ssl_crl	包含证书吊销列表的 PEM 格式文件的路径名。
ssl_crlpath	包含 PEM 格式证书吊销列表文件的目录路径名。
ssl_cipher	用于加密连接的可接受密码列表。
tls_version	服务器允许用于加密连接的 TLS 协议列表。
tls_ciphersuites	服务器允许用于加密连接的 TLSv1.3 密码套件。

重要提示

从 MySQL 8.0.28 版本开始，MySQL Server 移除了对 TLSv1 和 TLSv1.1 连接协议的支持。这些协议从 MySQL 8.0.26 开始被弃用，尽管 MySQL Server 客户端，包括作为客户端的 Group Replication 服务器实例，如果使用了弃用的 TLS 协议版本，不会向用户返回警告。有关更多信息，请参阅移除对 TLSv1 和 TLSv1.1 协议的支持。
从 MySQL 8.0.16 版本开始，MySQL Server 支持 TLSv1.3 协议，前提是 MySQL Server 使用 OpenSSL 1.1.1 进行编译。服务器在启动时检查 OpenSSL 的版本，如果低于 1.1.1，则将从与 TLS 版本相关的服务器系统变量的默认值中移除 TLSv1.3（包括 group_replication_recovery_tls_version 系统变量）。
MySQL 8.0.18 版本开始，Group Replication 支持 TLSv1.3。在 MySQL 8.0.16 和 MySQL 8.0.17 中，如果服务器支持 TLSv1.3，则协议不受组通信引擎支持，无法被 Group Replication 使用。
在 MySQL 8.0.18 中，TLSv1.3 可用于 Group Replication 的分布式恢复连接，但 group_replication_recovery_tls_version 和 group_replication_recovery_tls_ciphersuites 系统变量不可用。因此，捐赠服务器必须允许至少一个默认启用的 TLSv1.3 密码套件的使用，如第 8.3.2 节，“加密连接 TLS 协议和密码” 中所列。从 MySQL 8.0.19 开始，您可以使用选项配置客户端支持任何选择的密码套件，包括仅使用非默认密码套件。
在tls_version系统变量中指定的 TLS 协议列表中，确保指定的版本是连续的（例如，TLSv1.2,TLSv1.3）。如果协议列表中存在任何间隙（例如，如果您指定了TLSv1,TLSv1.2，省略了 TLS 1.1），Group Replication 可能无法建立组通信连接。

在一个复制组中，OpenSSL 协商使用所有成员支持的最高 TLS 协议。一个配置为仅使用 TLSv1.3（tls_version=TLSv1.3）的加入成员无法加入一个不支持 TLSv1.3 的复制组，因为在这种情况下，组成员使用较低的 TLS 协议版本。为了将成员加入到组中，您必须配置加入成员也允许使用现有组成员支持的较低的 TLS 协议版本。相反，如果一个加入成员不支持 TLSv1.3，但现有组成员都支持并且在彼此之间的连接中使用该版本，那么如果现有组成员已经允许使用合适的较低 TLS 协议版本，或者您对其进行配置，该成员可以加入。在这种情况下，OpenSSL 使用较低的 TLS 协议版本进行每个成员到加入成员的连接。每个成员与其他现有成员的连接继续使用两个成员都支持的最高可用协议。

从 MySQL 8.0.16 开始，您可以在运行时更改 tls_version 系统变量以更改服务器的允许 TLS 协议版本列表。请注意，对于 Group Replication，ALTER INSTANCE RELOAD TLS 语句重新配置服务器的 TLS 上下文，从定义上下文的系统变量的当前值中获取，不会在运行 Group Replication 时更改 Group Replication 的组通信连接的 TLS 上下文。要将重新配置应用于这些连接，必须执行 STOP GROUP_REPLICATION，然后执行 START GROUP_REPLICATION 以重新启动已更改 tls_version 系统变量的成员或成员的 Group Replication。同样，如果要使组的所有成员更改为使用更高或更低的 TLS 协议版本，必须在更改允许的 TLS 协议版本列表后，在成员上执行滚动重启 Group Replication，以便 OpenSSL 在完成滚动重启时协商使用更高的 TLS 协议版本。有关在运行时更改允许的 TLS 协议版本列表的说明，请参见第 8.3.2 节，“加密连接 TLS 协议和密码” 和服务器端运行时配置和监视加密连接。

以下示例显示了配置服务器上 SSL 并激活 SSL 用于组复制组通信连接的 my.cnf 文件中的部分内容：

[mysqld]
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
group_replication_ssl_mode= REQUIRED

重要提示

ALTER INSTANCE RELOAD TLS 语句重新配置服务器的 TLS 上下文，从定义上下文的系统变量的当前值中获取，不会在运行 Group Replication 时更改 Group Replication 的组通信连接的 TLS 上下文。要将重新配置应用于这些连接，必须执行 STOP GROUP_REPLICATION，然后执行 START GROUP_REPLICATION 以重新启动 Group Replication。

加入成员和现有成员之间进行的分布式恢复连接不受上述选项的覆盖。这些连接使用 Group Replication 的专用分布式恢复 SSL 选项，详细描述在第 20.6.3.2 节，“用于分布式恢复的安全套接字层（SSL）连接”。

当使用 MySQL 通信堆栈（group_replication_communication_stack=MYSQL）时： 分布式恢复组的安全设置应用于组成员之间的正常通信。请参阅第 20.6.3 节，“保护分布式恢复连接”以了解如何配置安全设置。

20.6.3 保护分布式恢复连接

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-distributed-recovery-securing.html

20.6.3.1 为分布式恢复保护用户凭据

20.6.3.2 为分布式恢复配置安全套接字层 (SSL) 连接

重要提示

当使用 MySQL 通信栈（group_replication_communication_stack=MYSQL）并且成员之间的连接是安全的（group_replication_ssl_mode 未设置为 DISABLED）时，本节讨论的安全设置不仅适用于分布式恢复连接，还适用于一般组成员之间的组通信。

当成员加入组时，分布式恢复是通过远程克隆操作（如果可用且适用）和异步复制连接的组合来执行的。有关分布式恢复的详细描述，请参见 Section 20.5.4, “Distributed Recovery”。

在 MySQL 8.0.20 版本之前，组成员根据 MySQL 服务器的 hostname 和 port 系统变量，为加入成员提供标准的 SQL 客户端连接，用于分布式恢复。从 MySQL 8.0.21 开始，组成员可以为加入成员提供一组备用的分布式恢复端点，作为专用的客户端连接。更多详情请参见 Section 20.5.4.1, “Connections for Distributed Recovery”。请注意，为分布式恢复提供给加入成员的连接并非用于 Group Replication 在使用 XCom 通信栈进行组通信时在线成员之间通信的连接（group_replication_communication_stack=XCOM）。

为了保护组内的分布式恢复连接，请确保复制用户的用户凭据得到妥善保护，并在可能的情况下使用 SSL 进行分布式恢复连接。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-secure-user.html

20.6.3.1 为分布式恢复安全用户凭据

从二进制日志进行状态传输需要具有正确权限的复制用户，以便 Group Replication 可以建立直接成员之间的复制通道。相同的复制用户用于所有组成员的分布式恢复。如果组成员已设置为支持作为分布式恢复的一部分的远程克隆操作（从 MySQL 8.0.17 开始提供），则此复制用户也用作捐赠者上的克隆用户，并且对于此角色也需要正确的权限。有关设置此用户的详细说明，请参阅第 20.2.1.3 节，“分布式恢复的用户凭据”。

为了保护用户凭据，您可以要求用户帐户的连接使用 SSL，并且（从 MySQL 8.0.21 开始）可以在启动 Group Replication 时提供用户凭据，而不是将它们存储在副本状态表中。此外，如果您使用缓存 SHA-2 认证，您必须在组成员上设置 RSA 密钥对。

重要

当使用 MySQL 通信堆栈（group_replication_communication_stack=MYSQL）和成员之间的安全连接（group_replication_ssl_mode未设置为DISABLED）时，恢复用户必须正确设置，因为他们也是组通信的用户。请按照第 20.6.3.1.2 节，“具有 SSL 的复制用户”和第 20.6.3.1.3 节，“安全提供复制用户凭据”中的说明进行操作。

20.6.3.1.1 具有缓存 SHA-2 认证插件的复制用户

默认情况下，在 MySQL 8 中创建的用户使用第 8.4.1.2 节，“缓存 SHA-2 可插拔认证”。如果您为分布式恢复配置的复制用户使用缓存 SHA-2 认证插件，并且不在分布式恢复连接中使用 SSL，那么 RSA 密钥对将用于密码交换。有关 RSA 密钥对的更多信息，请参阅第 8.3.3 节，“创建 SSL 和 RSA 证书和密钥”。

在这种情况下，您可以将rpl_user的公钥复制到加入成员，或者配置捐赠者在请求时提供公钥。更安全的方法是将复制用户帐户的公钥复制到加入成员。然后，您需要在加入成员上配置group_replication_recovery_public_key_path系统变量，指定复制用户帐户的公钥路径。

较不安全的方法是在捐赠者上设置group_replication_recovery_get_public_key=ON，以便它们向加入成员提供复制用户帐户的公钥。没有办法验证服务器的身份，因此只有在确定没有服务器身份被破坏的风险时才设置group_replication_recovery_get_public_key=ON，例如通过中间人攻击。

20.6.3.1.2 带 SSL 的复制用户

需要 SSL 连接的复制用户必须在服务器加入组（加入成员）连接到捐赠者之前创建。通常，在为服务器加入组进行配置时设置。要为需要 SSL 连接的分布式恢复创建一个复制用户，请在所有将参与组的服务器上发出以下语句：

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER '*rec_ssl_user*'@'%' IDENTIFIED BY '*password*' REQUIRE SSL;
mysql> GRANT REPLICATION SLAVE ON *.* TO '*rec_ssl_user*'@'%';
mysql> GRANT CONNECTION_ADMIN ON *.* TO '*rec_ssl_user*'@'%';
mysql> GRANT BACKUP_ADMIN ON *.* TO '*rec_ssl_user*'@'%';
mysql> GRANT GROUP_REPLICATION_STREAM ON *.* TO *rec_ssl_user*@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;

注意

当使用 MySQL 通信堆栈（group_replication_communication_stack=MYSQL）和成员之间的安全连接（group_replication_ssl_mode未设置为DISABLED）时，需要GROUP_REPLICATION_STREAM权限。参见第 20.6.1 节，“连接安全管理的通信堆栈”。

20.6.3.1.3 安全提供复制用户凭据

要为复制用户提供用户凭据，您可以将它们永久设置为group_replication_recovery通道的凭据，使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO语句。另外，从 MySQL 8.0.21 开始，您可以在每次启动群组复制时在START GROUP_REPLICATION语句中指定它们。在START GROUP_REPLICATION上指定的用户凭据优先于使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO语句设置的任何用户凭据。

使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO设置的用户凭据以明文形式存储在服务器上的复制元数据存储库中，但在START GROUP_REPLICATION中指定的用户凭据仅保存在内存中，并且通过STOP GROUP_REPLICATION语句或服务器关闭时会被删除。因此，使用START GROUP_REPLICATION指定用户凭据有助于保护群组复制服务器免受未经授权的访问。然而，这种方法与通过group_replication_start_on_boot系统变量指定自动启动群组复制不兼容。

如果要永久设置用户凭据，请在准备加入群组的成员上发出CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO语句：

mysql> CHANGE MASTER TO MASTER_USER='*rec_ssl_user*', MASTER_PASSWORD='*password*' 
            FOR CHANNEL 'group_replication_recovery';

Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='*rec_ssl_user*', SOURCE_PASSWORD='*password*' 
            FOR CHANNEL 'group_replication_recovery';

在首次启动群组复制或服务器重新启动时，要在START GROUP_REPLICATION上提供用户凭据，请发出以下语句：

mysql> START GROUP_REPLICATION USER='*rec_ssl_user*', PASSWORD='*password*';

重要提示

如果您切换到使用START GROUP_REPLICATION在以前使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO提供凭据的服务器上指定用户凭据，您必须完成以下步骤以获得此更改的安全性好处。

使用STOP GROUP_REPLICATION语句在组成员上停止组复制。虽然在组复制运行时可以执行以下两个步骤，但需要重新启动组复制以实施更改。

将group_replication_start_on_boot系统变量的值设置为OFF（默认为ON）。

通过发出以下语句从副本状态表中删除分布式恢复凭据：

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

Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='', SOURCE_PASSWORD='' 
            FOR CHANNEL 'group_replication_recovery';

使用指定分布式恢复用户凭据的START GROUP_REPLICATION语句在组成员上重新启动组复制。

如果不执行这些步骤，凭据将继续存储在副本状态表中，并且在远程克隆操作期间也可以传输到其他组成员，用于分布式恢复。然后，group_replication_recovery通道可能会意外地使用存储的凭据在原始成员或从原始成员克隆的成员上启动组复制。服务器启动时（包括远程克隆操作后）自动启动组复制将使用存储的用户凭据，如果操作员未在START GROUP_REPLICATION中指定分布式恢复凭据，则也会使用这些凭据。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-ssl-for-recovery.html

20.6.3.2 分布式恢复的安全套接字层（SSL）连接

重要

当使用 MySQL 通信堆栈（group_replication_communication_stack=MYSQL）和成员之间的安全连接（group_replication_ssl_mode 未设置为 DISABLED）时，本节讨论的安全设置不仅适用于分布式恢复连接，还适用于成员之间的组通信。请参阅 Section 20.6.1, “Communication Stack for Connection Security Management”。

无论是使用标准的 SQL 客户端连接还是分布式恢复端点进行分布式恢复连接，为了安全配置连接，您可以使用 Group Replication 的专用分布式恢复 SSL 选项。这些选项对应用于组通信连接的服务器 SSL 选项，但仅适用于分布式恢复连接。默认情况下，分布式恢复连接不使用 SSL，即使您为组通信连接激活了 SSL，服务器 SSL 选项也不适用于分布式恢复连接。您必须单独配置这些连接。

如果远程克隆操作作为分布式恢复的一部分使用，则 Group Replication 会自动配置克隆插件的 SSL 选项，以匹配您对分布式恢复 SSL 选项的设置。（有关克隆插件如何使用 SSL 的详细信息，请参阅为克隆配置加密连接。）

分布式恢复 SSL 选项如下：

group_replication_recovery_use_ssl：设置为 ON 以使 Group Replication 在分布式恢复连接中使用 SSL，包括远程克隆操作和从捐赠者的二进制日志进行状态传输。您可以只设置此选项，而不设置其他分布式恢复 SSL 选项，在这种情况下，服务器会自动生成用于连接的证书，并使用默认的密码套件。如果要为连接配置证书和密码套件，请使用其他分布式恢复 SSL 选项进行配置。
group_replication_recovery_ssl_ca: 用于分布式恢复连接的证书颁发机构（CA）文件的路径名。Group Replication 会自动配置克隆 SSL 选项clone_ssl_ca以匹配此路径。 group_replication_recovery_ssl_capath: 包含受信任 SSL 证书颁发机构（CA）证书文件的目录的路径名。
group_replication_recovery_ssl_cert: SSL 公钥证书文件的路径名，用于分布式恢复连接。Group Replication 会自动配置克隆 SSL 选项clone_ssl_cert以匹配此路径。
group_replication_recovery_ssl_key: SSL 私钥文件的路径名，用于分布式恢复连接。Group Replication 会自动配置克隆 SSL 选项clone_ssl_cert以匹配此路径。
group_replication_recovery_ssl_verify_server_cert: 使分布式恢复连接检查捐赠者发送证书中服务器的通用名称值。将此选项设置为ON相当于为群组通信连接的group_replication_ssl_mode选项设置VERIFY_IDENTITY。
group_replication_recovery_ssl_crl: 包含证书吊销列表的文件的路径名。
group_replication_recovery_ssl_crlpath: 包含证书吊销列表的目录的路径名。
group_replication_recovery_ssl_cipher: 用于分布式恢复连接的连接加密的可接受密码列表。指定一个或多个以冒号分隔的密码名称列表。有关 MySQL 支持的加密密码的信息，请参见第 8.3.2 节，“加密连接 TLS 协议和密码”。
group_replication_recovery_tls_version: 一个逗号分隔的列表，包含了在这个服务器实例作为分布式恢复连接的客户端（即加入成员）时，连接加密所允许的一个或多个 TLS 协议。此系统变量的默认值取决于 MySQL Server 版本中支持的 TLS 协议版本。每个作为客户端（加入成员）和服务器（捐赠者）参与每个分布式恢复连接的组成员协商他们都设置支持的最高协议版本。此系统变量从 MySQL 8.0.19 版本开始提供。
group_replication_recovery_tls_ciphersuites: 一个以冒号分隔的列表，包含了在使用 TLSv1.3 进行连接加密时，分布式恢复连接的客户端（即加入成员）时所允许的一个或多个密码套件。如果在使用 TLSv1.3 时将此系统变量设置为NULL（如果您没有设置系统变量，则默认为此），则允许默认启用的密码套件，如第 8.3.2 节“加密连接 TLS 协议和密码”中所列出的。如果将此系统变量设置为空字符串，则不允许使用任何密码套件，因此也不会使用 TLSv1.3。此系统变量从 MySQL 8.0.19 版本开始提供。

20.6.4 组复制 IP 地址权限

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-ip-address-permissions.html

仅当使用 XCom 通信堆栈建立组通信时（group_replication_communication_stack=XCOM），组复制插件允许您指定一个主机允许列表，从中可以接受传入的组通信系统连接。如果在服务器 s1 上指定了一个允许列表，那么当服务器 s2 正在与 s1 建立连接以进行组通信时，s1 在接受来自 s2 的连接之前首先检查允许列表。如果 s2 在允许列表中，则 s1 接受连接，否则 s1 拒绝 s2 的连接尝试。从 MySQL 8.0.22 开始，系统变量group_replication_ip_allowlist用于指定允许列表，而对于 MySQL 8.0.22 之前的版本，使用系统变量group_replication_ip_whitelist。新的系统变量的工作方式与旧的系统变量相同，只是术语已更改。

注意

当使用 MySQL 通信堆栈建立组通信时（group_replication_communication_stack=MYSQL），group_replication_ip_allowlist和group_replication_ip_whitelist的设置将被忽略。请参阅第 20.6.1 节，“连接安全管理的通信堆栈”。

如果您没有明确指定允许列表，则组通信引擎（XCom）会自动扫描主机上的活动接口，并识别具有私有子网地址的接口，以及为每个接口配置的子网掩码。这些地址以及 IPv4 的localhost IP 地址和（从 MySQL 8.0.14 开始）IPv6 用于创建自动组复制允许列表。因此，自动允许列表包括在适当的子网掩码应用后在主机中找到的以下范围的任何 IP 地址：

IPv4 (as defined in RFC 1918)
10/8 prefix       (10.0.0.0 - 10.255.255.255) - Class A
172.16/12 prefix  (172.16.0.0 - 172.31.255.255) - Class B
192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class C

IPv6 (as defined in RFC 4193 and RFC 5156)
fc00:/7 prefix    - unique-local addresses
fe80::/10 prefix  - link-local unicast addresses

127.0.0.1 - localhost for IPv4
::1       - localhost for IPv6

在错误日志中添加了一个条目，指出已自动允许主机的地址。

自动允许私有地址的白名单不能用于来自私有网络之外的服务器的连接，因此，即使服务器具有公共 IP 接口，也不会默认允许外部主机从外部连接到 Group Replication。对于位于不同机器上的服务器实例之间的 Group Replication 连接，您必须提供公共 IP 地址并将其指定为显式白名单。如果您为白名单指定任何条目，则私有和localhost地址不会自动添加，因此，如果您使用其中任何一个，必须明确指定。

要手动指定白名单，请使用group_replication_ip_allowlist（MySQL 8.0.22 及更高版本）或group_replication_ip_whitelist系统变量。在 MySQL 8.0.24 之前，您不能在服务器作为复制组的活动成员时更改白名单。如果成员处于活动状态，则必须在更改白名单之前执行STOP GROUP_REPLICATION，然后执行更改白名单，并在之后执行START GROUP_REPLICATION。从 MySQL 8.0.24 开始，您可以在 Group Replication 运行时更改白名单。

白名单必须包含在每个成员的group_replication_local_address系统变量中指定的 IP 地址或主机名。此地址与 MySQL 服务器 SQL 协议主机和端口不同，并且不在服务器实例的bind_address系统变量中指定。如果用作服务器实例的 Group Replication 本地地址的主机名解析为 IPv4 和 IPv6 地址，则 IPv4 地址优先用于 Group Replication 连接。

指定为分布式恢复端点的 IP 地址以及如果用于分布式恢复（这是默认设置）的成员标准 SQL 客户端连接的 IP 地址不需要添加到白名单中。白名单仅用于每个成员的group_replication_local_address指定的地址。加入成员必须通过白名单允许其对组的初始连接，以便检索用于分布式恢复的地址或地址。

在白名单中，您可以指定以下任意组合：

IPv4 地址（例如，198.51.100.44）
具有 CIDR 表示法的 IPv4 地址（例如，192.0.2.21/24）
IPv6 地址，从 MySQL 8.0.14 开始（例如，2001:db8:85a3:8d3:1319:8a2e:370:7348）
具有 CIDR 表示法的 IPv6 地址，从 MySQL 8.0.14 开始（例如，2001:db8:85a3:8d3::/64）
主机名（例如，example.org）
使用 CIDR 表示法的主机名（例如，www.example.com/24）

在 MySQL 8.0.14 之前，主机名只能解析为 IPv4 地址。从 MySQL 8.0.14 开始，主机名可以解析为 IPv4 地址、IPv6 地址或两者都可以。如果一个主机名同时解析为 IPv4 和 IPv6 地址，则始终使用 IPv4 地址进行组复制连接。您可以结合主机名或 IP 地址使用 CIDR 表示法来允许具有特定网络前缀的 IP 地址块，但请确保指定子网中的所有 IP 地址都在您的控制范围内。

注意

当因为 IP 地址不在允许列表中而拒绝连接尝试时，拒绝消息总是以 IPv6 格式打印 IP 地址。在此格式中，IPv4 地址以::ffff:开头（一个 IPv4 映射的 IPv6 地址）。您不需要使用此格式来指定允许列表中的 IPv4 地址；对于 IPv4 地址，请使用标准 IPv4 格式。

在允许列表中，每个条目之间必须用逗号分隔。例如：

mysql> SET GLOBAL group_replication_ip_allowlist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24";

要加入复制组，服务器需要在其请求加入组的种子成员上获得许可。通常，这将是复制组的引导成员，但可以是任何在服务器配置中由group_replication_group_seeds选项列出的服务器之一。如果组的任何种子成员在加入成员具有 IPv4 group_replication_local_address时使用 IPv6 地址列出，或反之亦然，则还必须为加入成员为种子成员提供的协议设置和允许备用地址（或解析为该协议地址的主机名）。这是因为当服务器加入复制组时，必须使用种子成员在group_replication_group_seeds选项中广告的协议进行初始联系，无论是 IPv4 还是 IPv6。如果加入成员没有适当协议的允许地址，其连接尝试将被拒绝。有关管理混合 IPv4 和 IPv6 复制组的更多信息，请参见第 20.5.5 节，“IPv6 和混合 IPv6 和 IPv4 组的支持”。

当重新配置复制组（例如，选举新的主服务器或成员加入或离开时），组成员之间重新建立连接。如果一个组成员只被不再是复制组一部分的服务器允许访问，那么在重新配置后，它将无法重新连接到不允许它的剩余服务器。为了完全避免这种情况，请为所有作为复制组成员的服务器指定相同的白名单。

注意

根据您的安全要求，可以为不同的组成员配置不同的白名单，例如，为了保持不同的子网分开。如果您需要配置不同的白名单以满足安全要求，请确保在复制组中的白名单之间有足够的重叠，以最大限度地增加服务器在没有原始种子成员的情况下重新连接的可能性。

对于主机名，名称解析仅在另一个服务器发出连接请求时进行。无法解析的主机名不会被考虑用于白名单验证，并且会将警告消息写入错误日志。对已解析的主机名执行前向确认反向 DNS（FCrDNS）验证。

警告

主机名在白名单中比 IP 地址不安全。FCrDNS 验证提供了很好的保护水平，但可能会受到某些类型攻击的影响。仅在绝对必要时在白名单中指定主机名，并确保所有用于名称解析的组件，如 DNS 服务器，都在您的控制之下。您还可以使用 hosts 文件在本地实现名称解析，以避免使用外部组件。

20.7 群组复制性能和故障排除

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance.html

20.7.1 调整群组通信线程

20.7.2 流量控制

20.7.3 单一共识领导者

20.7.4 消息压缩

20.7.5 消息分段

20.7.6 XCom 缓存管理

20.7.7 对故障检测和网络分区的响应

20.7.8 处理网络分区和法定人数丢失

20.7.9 使用性能模式内存工具监控群组复制内存使用情况

群组复制旨在创建具有内置故障检测和自动恢复功能的容错系统。如果成员服务器实例自愿离开或停止与群组通信，剩余成员将在彼此之间达成群组重新配置的协议，并在需要时选择新的主服务器。被驱逐的成员会自动尝试重新加入群组，并通过分布式恢复使其保持最新。如果一个群组遇到困难，以至于无法与大多数成员联系以达成决策，它会标识自己已失去法定人数并停止处理事务。群组复制还具有内置机制和设置，帮助群组适应和管理工作负载和消息大小的变化，并保持在底层系统和网络资源的限制范围内。

群组复制的系统变量默认设置旨在最大化群组的性能和自主性。本节中的信息旨在帮助您配置一个复制群组，以优化自动处理您在特定系统上遇到的任何经常性问题，例如瞬时网络中断或超出服务器实例资源的工作负载和事务。

如果发现群组成员被频繁驱逐并重新加入群组，可能是因为群组复制的默认故障检测设置对您的系统过于敏感。这可能发生在较慢的网络或机器上，网络出现高频率的意外瞬时中断，或计划中的网络中断期间。有关通过调整设置处理该情况的建议，请参阅第 20.7.7 节“对故障检测和网络分区的响应”。

只有在 Group Replication 设置中发生组无法自动处理的情况时，您才需要手动干预。一些可能需要管理员干预的关键问题是当成员处于ERROR状态且无法重新加入组时，或者当网络分区导致组失去法定人数时。

如果一个本来正常运行和配置的成员无法使用分布式恢复加入或重新加入组，并且保持在ERROR状态，Section 20.5.4.4, “Fault Tolerance for Distributed Recovery”，解释了可能出现的问题。一个可能的原因是加入成员有额外的事务，这些事务在组的现有成员中不存在。有关处理这种情况的建议，请参阅 Section 20.4.1, “GTIDs and Group Replication”。
如果一个组失去了法定人数，这可能是由于网络分区将组分成两部分，或者可能是由于大多数服务器的故障。有关处理这种情况的建议，请参阅 Section 20.7.8, “Handling a Network Partition and Loss of Quorum”。

20.7.1 优化组通信线程

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-fine-tuning-the-group-communication-thread.html

当 Group Replication 插件加载时，组通信线程（GCT）在循环中运行。GCT 从组和插件接收消息，处理关于法定人数和故障检测的任务，发送一些保持活动的消息，并处理来自/发送到服务器/组的传入和传出事务。GCT 在队列中等待传入消息。当没有消息时，GCT 会等待。在实际进入睡眠之前，通过将这种等待时间设置得稍长一些（进行主动等待）可能在某些情况下证明是有益的。这是因为另一种选择是操作系统将 GCT 从处理器中切换出来并进行上下文切换。

要强制 GCT 进行主动等待，使用 group_replication_poll_spin_loops 选项，使 GCT 在实际轮询队列获取下一条消息之前，循环执行无关紧要的操作，达到配置的循环次数。

例如：

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

20.7.2 流量控制

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-flow-control.html

20.7.2.1 探针和统计信息

20.7.2.2 Group Replication 限流

Group Replication 确保事务仅在组中的大多数成员接收并就同时发送的所有事务之间的相对顺序达成一致后才提交。如果组中的总写入次数超过任何成员的写入容量，则此方法效果良好。如果确实如此，并且一些成员的写入吞吐量低于其他成员，特别是低于写入成员，则这些成员可能会开始落后于写入者。

使一些成员落后于组带来一些问题后果，特别是，这些成员上的读取可能会显示非常旧的数据。根据成员落后的原因，组中的其他成员可能需要保存更多或更少的复制上下文，以便能够满足来自慢速成员的潜在数据传输请求。

然而，在复制协议中有一种机制可以避免快速成员和慢速成员之间在应用的事务方面有太大的距离。这被称为流量控制机制。它试图解决几个目标：

保持成员之间足够接近，使缓冲和成员之间的去同步问题变得不那么严重；
快速适应不同工作负载或组中更多写入者等不同条件；
给每个成员公平分享可用写入容量；
不要将吞吐量降低到绝对必要的程度以避免浪费资源。

考虑到 Group Replication 的设计，是否进行限流取决于两个工作队列：(i) 认证队列；(ii) 以及二进制日志 应用程序 队列。每当其中一个队列的大小超过用户定义的阈值时，限流机制就会被触发。只需配置：(i) 在认证者或应用程序级别进行流量控制，或两者都进行；以及 (ii) 每个队列的阈值是多少。

流量控制取决于两种基本机制：

监控成员以收集有关所有组成员的吞吐量和队列大小的一些统计信息，以便对每个成员应受到的最大写入压力进行合理猜测；
对于试图在每个时间点写入超出其公平份额的成员进行限流。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-probes-and-statistics.html

20.7.2.1 探针和统计信息

监控机制通过每个成员部署一组探针来收集有关其工作队列和吞吐量的信息来运作。然后定期将该信息传播给组，以与其他成员共享数据。

这些探针分散在插件堆栈中，允许建立诸如以下指标：

认证者队列大小；
复制应用程序队列大小；
已认证的事务总数；
在成员中应用的远程事务总数；
本地事务总数。

一旦成员收到来自另一成员的带有统计信息的消息，它会计算关于上一个监控周期内认证、应用和本地执行的事务数量的其他指标。

监控数据定期与组内其他成员共享。监控周期必须足够长，以便其他成员决定当前的写入请求，但又足够短，以便对组带宽影响最小。信息每秒共享一次，这个周期足以解决这两个问题。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-throttling.html

20.7.2.2 组复制限流

基于在组中所有服务器收集的指标，限流机制会启动并决定是否限制成员能够执行/提交新事务的速率。

因此，从所有成员获取的指标是计算每个成员容量的基础：如果成员有一个大队列（用于认证或应用程序线程），那么执行新事务的能力应该接近上个周期认证或应用的事务。

组中所有成员的最低容量确定了组的实际容量，而本地事务的数量确定了有多少成员正在向其写入，因此，可用容量应该与多少成员共享。

这意味着每个成员都有一个根据可用容量确定的已建立的写入配额，换句话说，它可以安全地为下一个周期发出的事务数量。如果认证者或二进制日志应用程序的队列大小超过用户定义的阈值，写入配额将由限流机制执行。

配额将减少上个周期延迟的事务数量，然后再减少 10%，以允许触发问题的队列减小其大小。为了避免一旦队列大小超过阈值就出现大幅增加的吞吐量，吞吐量在此后每个周期只允许增长相同的 10%。

当前的限流机制不会对低于配额的事务进行惩罚，但会延迟完成那些超出配额的事务，直到监控周期结束。因此，如果写请求的配额非常小，一些事务的延迟可能接近监控周期。

20.7.3 单一共识领导者

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-single-consensus-leader.html

默认情况下，Group Replication 的组通信引擎（XCom，一种 Paxos 变体）使用复制组的每个成员作为领导者。从 MySQL 8.0.27 开始，当组处于单主模式时，组通信引擎可以使用单个领导者来驱动共识。在单主模式下使用单一共识领导者可以提高性能和韧性，特别是当组的某些次要成员当前无法访问时。

要使用单一共识领导者，组必须按以下方式配置：

组必须处于单主模式。
group_replication_paxos_single_leader 系统变量必须设置为 ON。默认设置为 OFF 时，该行为被禁用。您必须对复制组进行完全重启（引导）以使 Group Replication 生效对此设置的更改。
Group Replication 通信协议版本必须设置为 8.0.27 或更高。使用 group_replication_get_communication_protocol() 函数查看组的通信协议版本。如果使用较低版本，则组无法使用此行为。如果所有组成员都支持，您可以使用 group_replication_set_communication_protocol() 函数将组的通信协议设置为更高版本。MySQL InnoDB Cluster 会自动管理通信协议版本。有关更多信息，请参见 Section 20.5.1.4, “Setting a Group’s Communication Protocol Version”。

当配置完成后，Group Replication 指示组通信引擎使用组的主节点作为单一领导者来驱动共识。当选举出新的主节点时，Group Replication 会告知组通信引擎使用新的主节点。如果主节点当前不健康，组通信引擎会使用其他成员作为共识领导者。性能模式表 replication_group_communication_information 显示当前首选和实际共识领导者，首选领导者是 Group Replication 的选择，实际领导者是组通信引擎选择的领导者。

如果组处于多主模式，具有较低的通信协议版本，或者行为被group_replication_paxos_single_leader设置禁用，则所有成员都被用作领导者来推动共识。在这种情况下，性能模式表replication_group_communication_information显示所有成员都是首选和实际领导者。

在性能模式表replication_group_communication_information中的字段WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE显示组是否支持使用单个领导者，即使在查询的成员上当前设置为OFF的group_replication_paxos_single_leader。如果组是在启动时使用group_replication_paxos_single_leader设置为ON，并且其通信协议版本为 MySQL 8.0.27 或更高版本，则该字段设置为 1。此信息仅对处于ONLINE或RECOVERING状态的组成员返回。

20.7.4 消息压缩

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-message-compression.html

对于在线群组成员之间发送的消息，Group Replication 默认启用消息压缩。特定消息是否被压缩取决于您使用group_replication_compression_threshold系统变量配置的阈值。超过指定字节数的有效载荷的消息将被压缩。

默认压缩阈值为 1000000 字节。您可以使用以下语句将压缩阈值增加到 2MB，例如：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold = 2097152;
START GROUP_REPLICATION;

如果将group_replication_compression_threshold设置为零，则消息压缩将被禁用。

Group Replication 使用 LZ4 压缩算法来压缩组内发送的消息。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。这个限制低于group_replication_compression_threshold系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。因此，LZ4 最大输入大小是消息压缩的实际限制，当启用消息压缩时，超过此大小的事务无法提交。使用 LZ4 压缩算法时，请不要为group_replication_compression_threshold设置大于 2113929216 字节的值。

Group Replication 不要求所有组成员的group_replication_compression_threshold的值相同。然而，建议在所有组成员上设置相同的值，以避免事务不必要的回滚、消息传递失败或消息恢复失败。

从 MySQL 8.0.18 开始，您还可以为通过从捐赠者的二进制日志进行状态传输的分布式恢复发送的消息配置压缩。这些消息的压缩，从已在组中的捐赠者发送到加入成员，是通过group_replication_recovery_compression_algorithms和group_replication_recovery_zstd_compression_level系统变量分别控制。有关更多信息，请参见 Section 6.2.8，“连接压缩控制”。

二进制日志事务压缩（自 MySQL 8.0.20 起可用），由binlog_transaction_compression系统变量激活，也可用于节省带宽。当事务负载在组成员之间传输时保持压缩。如果您将二进制日志事务压缩与 Group Replication 的消息压缩结合使用，消息压缩的作用机会较少，但仍可压缩标头以及未压缩的事件和事务负载。有关二进制日志事务压缩的更多信息，请参见 Section 7.4.4.5，“二进制日志事务压缩”。

组内发送的消息的压缩发生在组通信引擎级别，即在数据交给组通信线程之前，因此在mysql用户会话线程的上下文中进行。如果消息负载大小超过group_replication_compression_threshold设置的阈值，事务负载在发送到组之前会被压缩，并在接收时解压缩。接收消息时，成员会检查消息信封以验证是否已压缩。如果需要，则成员在将事务传递到上层之前对其进行解压缩。此过程如下图所示。

图 20.13 压缩支持

MySQL Group Replication 插件架构如前文所述，插件的五个层位于 MySQL 服务器和复制组之间。压缩和解压缩由 Group Communication System API 处理，这是 Group Replication 插件的第四层。组通信引擎（插件的第五层）和组成员使用数据量较小的压缩事务。MySQL 服务器核心和 Group Replication 插件的三个更高层（API、捕获、应用和恢复组件以及复制协议模块）使用数据量较大的原始事务。

当网络带宽成为瓶颈时，消息压缩可以在组通信级别提供高达 30-40%的吞吐量改进。这在负载下的大型服务器组的情况下尤为重要。组内N个参与者之间的互连是 TCP 点对点的性质，使发送方将相同数量的数据发送N次。此外，二进制日志可能具有较高的压缩比。这使得压缩成为包含大型事务的 Group Replication 工作负载的一个引人注目的特性。

20.7.5 消息分段

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-message-fragmentation.html

当在 Group Replication 组成员之间发送异常大的消息时，可能导致一些组成员被报告为失败并从组中驱逐。这是因为 Group Replication 的组通信引擎（XCom，一种 Paxos 变体）使用的单个线程在处理消息时占用时间过长，因此一些组成员可能会将接收者报告为失败。从 MySQL 8.0.16 开始，默认情况下，大消息会自动分割成单独发送并由接收方重新组装的片段。

系统变量group_replication_communication_max_message_size指定了 Group Replication 通信的最大消息大小，超过该大小的消息将被分段。默认的最大消息大小为 10485760 字节（10 MiB）。允许的最大值与replica_max_allowed_packet和slave_max_allowed_packet系统变量的最大值相同，即 1073741824 字节（1 GB）。group_replication_communication_max_message_size的设置必须小于replica_max_allowed_packet或slave_max_allowed_packet的设置，因为应用程序线程无法处理大于最大允许数据包大小的消息片段。要关闭分段，为group_replication_communication_max_message_size指定零值。

与大多数其他 Group Replication 系统变量一样，必须重新启动 Group Replication 插件才能使更改生效。例如：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_communication_max_message_size= 5242880;
START GROUP_REPLICATION;

分段消息的消息传递在所有组成员接收并重新组装消息的所有片段后被视为完成。分段消息在其标头中包含信息，使得在消息传输过程中加入的成员能够恢复其加入之前发送的早期片段。如果加入的成员未能恢复片段，则会自行从组中退出。

为了使复制组使用分片，所有组成员必须在 MySQL 8.0.16 或更高版本，并且组使用的 Group Replication 通信协议版本必须允许分片。您可以使用group_replication_get_communication_protocol()函数检查组使用的通信协议，该函数返回组支持的最旧的 MySQL Server 版本。从 MySQL 5.7.14 版本开始允许消息压缩，从 MySQL 8.0.16 版本开始还允许消息分片。如果所有组成员都在 MySQL 8.0.16 或更高版本，并且没有要求允许早期版本的成员加入，您可以使用group_replication_set_communication_protocol()函数将通信协议版本设置为 MySQL 8.0.16 或更高版本，以允许分片。有关更多信息，请参见第 20.5.1.4 节，“设置组的通信协议版本”。

如果一个复制组由于某些成员不支持而无法使用分片，系统变量group_replication_transaction_size_limit可以用来限制组接受的事务的最大大小。在 MySQL 8.0 中，默认设置约为 143 MB。超过此大小的事务将被回滚。您还可以使用系统变量group_replication_member_expel_timeout来允许额外的时间（最长一小时），在怀疑已经失败的成员被从组中驱逐之前。

20.7.6 XCom 缓存管理

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache.html

20.7.6.1 增加缓存大小

20.7.6.2 减少缓存大小

用于 Group Replication 的组通信引擎（XCom，一种 Paxos 变体）包括一个用于在共识协议的一部分中交换组成员之间的消息（及其元数据）的缓存。消息缓存除了其他功能外，还用于在成员在与其他组成员无法通信的一段时间后重新连接到组时恢复丢失的消息。

从 MySQL 8.0.16 开始，可以使用group_replication_message_cache_size系统变量为 XCom 的消息缓存设置缓存大小限制。如果达到缓存大小限制，XCom 会删除已经决定和传递的最旧条目。因为正在尝试重新连接的不可达成员会随机选择任何其他成员来恢复丢失的消息，所以所有组成员都应该设置相同的缓存大小限制。因此，每个成员的缓存中应该有相同的消息。

在 MySQL 8.0.16 之前，缓存大小为 1 GB，从 MySQL 8.0.16 开始，默认设置的缓存大小相同。请确保系统上有足够的内存可用于您选择的缓存大小限制，考虑到 MySQL Server 的其他缓存和对象池的大小。请注意，使用group_replication_message_cache_size设置的限制仅适用于缓存中存储的数据，缓存结构需要额外的 50 MB 内存。

在选择group_replication_message_cache_size设置时，应参考成员被驱逐之前的时间段内预期的消息量。这段时间的长度由group_replication_member_expel_timeout系统变量控制，该变量确定了等待期限（最长一小时），除了成员最初的 5 秒检测期外，允许成员返回到组中而不被驱逐。请注意，在 MySQL 8.0.21 之前，这段时间默认为成员变得不可用后的 5 秒，这只是在产生怀疑之前的检测期，因为group_replication_member_expel_timeout系统变量设置的额外驱逐超时默认为零。从 8.0.21 开始，驱逐超时默认为 5 秒，因此默认情况下，成员在至少离开 10 秒后才会被驱逐。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache-increase.html

20.7.6.1 增加缓存大小

如果一个成员缺席的时间不够长，以至于还没有被从组中驱逐，它可以重新连接并从另一个成员的 XCom 消息缓存中检索丢失的事务，然后再次参与组。然而，如果在成员缺席期间发生的事务已经被从其他成员的 XCom 消息缓存中删除，因为它们达到了最大大小限制，那么该成员无法通过这种方式重新连接。

Group Replication 的组通信系统（GCS）通过警告消息向您发出警告，当一个消息被从消息缓存中删除时，这个消息可能会被当前不可达的成员用于恢复。这个警告消息被记录在所有活动组成员上（对于每个不可达成员只记录一次）。尽管组成员无法确定不可达成员看到的最后一条消息是什么，但警告消息表明缓存大小可能不足以支持您选择的成员被驱逐之前的等待时间。

在这种情况下，考虑根据group_replication_member_expel_timeout系统变量指定的时间段内预期的消息量，再加上 5 秒的检测期，来增加group_replication_message_cache_size限制，以便缓存包含所有成员成功返回所需的所有丢失消息。如果预计某个成员将在异常时间内变得不可达，还可以考虑暂时增加缓存大小限制。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache-reduce.html

20.7.6.2 减小缓存大小

XCom 消息缓存大小的最小设置是 1 GB，直到 MySQL 8.0.20 版本。从 MySQL 8.0.21 开始，最小设置为 134217728 字节（128 MB），这使得可以在可用内存量受限的主机上部署。如果主机处于不稳定网络上，不建议将group_replication_message_cache_size设置得非常低，因为较小的消息缓存会使组成员在短暂失去连接后更难重新连接。

如果重新连接的成员无法从 XCom 消息缓存中检索到所需的所有消息，则该成员必须离开组并重新加入，以从另一个成员的二进制日志中使用分布式恢复检索缺失的事务。从 MySQL 8.0.21 开始，默认情况下，离开组的成员会进行三次自动重新加入尝试，因此重新加入组的过程可以在没有操作员干预的情况下进行。然而，使用分布式恢复重新加入是一个明显更长且更复杂的过程，比从 XCom 消息缓存中检索消息需要更长时间，因此成员需要更长时间才能变得可用，组的性能可能会受到影响。在稳定网络上，可以最小化成员短暂失去连接的频率和持续时间，因此这种情况发生的频率也应该最小化，因此组可能能够容忍较小的 XCom 消息缓存大小而不会对其性能产生显著影响。

如果您考虑减小缓存大小限制，可以使用以下语句查询 Performance Schema 表memory_summary_global_by_event_name：

SELECT * FROM performance_schema.memory_summary_global_by_event_name
  WHERE EVENT_NAME LIKE 'memory/group_rpl/GCS_XCom::xcom_cache';

这返回消息缓存的内存使用统计，包括当前缓存条目数和当前缓存大小。如果您减小缓存大小限制，XCom 会删除已经决定和传递的最旧条目，直到当前大小低于限制。在此移除过程进行时，XCom 可能暂时超过缓存大小限制。

20.7.7 响应故障检测和网络分区

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html

20.7.7.1 驱逐超时

20.7.7.2 不可达多数超时

20.7.7.3 自动重新加入

20.7.7.4 退出操作

组复制的故障检测机制旨在识别不再与组通信并在看似可能已经失败时将其驱逐的组成员。拥有故障检测机制增加了组包含大多数正常工作成员的机会，因此客户端的请求能够被正确处理。

通常，所有组成员定期与所有其他组成员交换消息。如果某个组成员在 5 秒内没有收到来自特定成员的任何消息，当检测期结束时，会对该成员产生怀疑。当怀疑超时时，被怀疑的成员被认为已经失败，并被驱逐出组。被驱逐的成员从其他成员看到的成员列表中被移除，但它并不知道自己已经被驱逐出组，因此它认为自己在线，而其他成员无法到达。如果成员实际上没有失败（例如，因为仅因临时网络问题而断开连接），并且能够恢复与其他成员的通信，它将接收一个包含其被驱逐出组信息的视图。

组成员对这些情况的响应，包括故障成员本身，在整个过程中可以进行配置。默认情况下，如果怀疑某个成员已经失败，则会发生以下行为：

在 MySQL 8.0.20 之前，当产生怀疑时，立即超时。一旦组识别到已过期的怀疑，被怀疑的成员就有可能在超时后的几秒内存活，因为定期进行过期怀疑检查。从 MySQL 8.0.21 开始，在怀疑超时并且被怀疑的成员有可能被驱逐之前，会添加 5 秒的等待时间。
如果被驱逐的成员恢复通信并意识到自己已被驱逐，在 MySQL 8.0.20 之前，它不会尝试重新加入组。从 MySQL 8.0.21 开始，它将自动尝试三次重新加入组（每次尝试之间间隔 5 分钟），如果此自动重新加入过程不起作用，则停止尝试重新加入组。
当被驱逐的成员不尝试重新加入组时，它会切换到超级只读模式并等待操作员注意。（例外情况是在 MySQL 8.0.12 至 8.0.15 的版本中，默认情况下成员会关闭自身。从 MySQL 8.0.16 开始，行为已更改以匹配 MySQL 5.7 中的行为。）

您可以使用本节中描述的组复制配置选项来永久或临时更改这些行为，以适应您系统的要求和您的优先级。如果您遇到由较慢的网络或机器引起的不必要的驱逐、具有高意外瞬时中断率的网络，或计划中的网络中断，考虑增加驱逐超时和自动重新加入尝试次数。从 MySQL 8.0.21 开始，已更改默认设置以减少在这些情况下需要操作员干预以恢复被驱逐成员的频率。请注意，虽然成员正在经历上述任何默认行为之一时，尽管它不接受写入，但如果成员仍在与客户端通信，则仍然可以进行读取，随着时间的推移，过时读取的可能性会增加。如果避免过时读取对您而言比避免操作员干预更重要，请考虑减少驱逐超时和自动重新加入尝试次数或将其设置为零。

未发生故障的成员可能会由于网络分区而失去与复制组的部分但不是全部的联系。例如，在一个由 5 台服务器（S1、S2、S3、S4、S5）组成的组中，如果（S1、S2）和（S3、S4、S5）之间存在断开连接，则存在网络分区。第一组（S1、S2）现在处于少数派，因为它无法与超过一半的组联系。由少数派组成员处理的任何事务都会被阻塞，因为组的大多数是不可达的，因此组无法达成法定人数。有关此场景的详细描述，请参见第 20.7.8 节，“处理网络分区和法定人数丧失”。在这种情况下，默认行为是使少数派和多数派的成员继续留在组中，继续接受事务（尽管在少数派成员上被阻塞），并等待操作员干预。此行为也是可配置的。

请注意，如果团队成员使用的是较旧的 MySQL 服务器版本，不支持相关设置，或者使用具有不同默认设置的版本，则他们会根据上述默认行为对自己和其他团队成员采取行动。例如，不支持group_replication_member_expel_timeout系统变量的成员会在检测到过期的怀疑时立即驱逐其他成员，并即使其他成员支持该系统变量并设置了更长的超时时间，他们也会接受这种驱逐。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure-expel.html

20.7.7.1 驱逐超时

你可以使用group_replication_member_expel_timeout系统变量，该变量从 MySQL 8.0.13 开始提供，以允许在怀疑创建和怀疑成员被驱逐之间提供额外时间。当一个服务器没有从另一个服务器接收消息时，就会创建怀疑，如第 20.1.4.2 节“故障检测”中所解释的那样。

在 Group Replication 组成员创建对另一个成员（或自身）的怀疑之前，会有一个初始的 5 秒检测期。然后，在另一个成员对其（或自身对自身）的怀疑超时后，该组成员将被驱逐。在此之后可能会有一个短暂的时间段，然后驱逐机制会检测并执行驱逐。group_replication_member_expel_timeout指定了在创建怀疑和驱逐被怀疑成员之间等待的时间段，称为驱逐超时，期间组成员被列为UNREACHABLE，但不会从组的成员列表中移除。

如果怀疑成员在等待期结束时再次活动，成员将应用由剩余组成员在 XCom 消息缓存中缓冲的所有消息，并进入ONLINE状态，无需操作员干预。在这种情况下，组将认为该成员是同一实例。
如果怀疑成员在怀疑超时后才重新活动并能恢复通信，它会收到一个被驱逐的视图，此时意识到自己被驱逐。你可以使用group_replication_autorejoin_tries系统变量，该变量从 MySQL 8.0.16 开始提供，使成员在此时自动尝试重新加入组。从 MySQL 8.0.21 开始，默认情况下激活此功能，并且成员会进行三次自动重新加入尝试。如果自动重新加入过程失败或未尝试，则被驱逐成员将按照group_replication_exit_state_action指定的退出操作进行。

在驱逐成员之前的等待时间仅适用于先前在组中活动过的成员。从未在组中活动过的非成员不会获得此等待时间，并且在初始检测期结束后因加入时间过长而被移除。

如果group_replication_member_expel_timeout设置为 0，则没有等待期，而在 5 秒检测期结束后，疑似成员立即有可能被驱逐。这是 MySQL 8.0.20 及更早版本的默认设置。这也是不支持group_replication_member_expel_timeout系统变量的 MySQL 服务器版本的组成员的行为。从 MySQL 8.0.21 开始，默认值为 5，意味着在 5 秒检测期后的 5 秒内，疑似成员有可能被驱逐。并非所有组成员都必须具有相同的group_replication_member_expel_timeout设置，但建议这样做以避免意外驱逐。任何成员都可以对任何其他成员（包括自身）产生怀疑，因此有效的驱逐超时是具有最低设置的成员的超时。

在以下情况下考虑增加group_replication_member_expel_timeout的值，而不使用默认值：

网络速度较慢，默认的 5 或 10 秒在驱逐之前不足以确保组成员始终交换至少一条消息。
网络有时会出现短暂中断，您希望在这些时候避免不必要的驱逐和主要成员更改。
网络不在您的直接控制之下，您希望最大程度减少操作员干预的需求。
预计会发生临时网络中断，您不希望因此而有些或全部成员被驱逐。
个别机器正在经历减速，您不希望它被从组中驱逐。

您可以指定最长达 3600 秒（1 小时）的驱逐超时。重要的是要确保 XCom 的消息缓存足够大，以容纳在指定时间段内预期的消息量，再加上初始的 5 秒检测期，否则成员无法重新连接。您可以使用group_replication_message_cache_size系统变量来调整缓存大小限制。有关更多信息，请参见第 20.7.6 节，“XCom 缓存管理”。

如果一个群组中的任何成员目前受到怀疑，那么群组成员资格不能重新配置（通过添加或删除成员或选举新领导者）。如果需要实施群组成员变更，而其中一个或多个成员受到怀疑，并且你希望怀疑成员继续留在群组中，那么请采取任何必要行动使这些成员重新活跃，如果可能的话。如果你无法使这些成员重新活跃，并且希望将他们从群组中驱逐，你可以立即强制怀疑超时。方法是在任何活跃成员上更改group_replication_member_expel_timeout的值为低于自怀疑创建以来已经经过的时间的值。这样一来，怀疑成员将立即有可能被驱逐。

如果一个复制组成员意外停止并立即重新启动（例如，因为它是使用mysqld_safe启动的），如果设置了group_replication_start_on_boot=on，它会自动尝试重新加入群组。在这种情况下，重新启动和重新加入尝试可能发生在成员的先前实例被驱逐出群组之前，这样该成员就无法重新加入。从 MySQL 8.0.19 开始，Group Replication 自动使用群组通信系统（GCS）功能为成员重试重新加入尝试 10 次，每次重试之间间隔 5 秒。这应该涵盖大多数情况，并允许足够的时间让先前的实例被驱逐出群组，从而让成员重新加入。请注意，如果group_replication_member_expel_timeout系统变量设置为指定成员被驱逐之前等待的较长时间，自动重新加入尝试可能仍然不会成功。

对于在group_replication_member_expel_timeout系统变量不可用的情况下避免不必要驱逐的替代缓解策略，请参阅 Section 20.3.2, “Group Replication Limitations”。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure-partition.html

20.7.7.2 不可达多数超时

默认情况下，由于网络分区而处于少数派的成员不会自动离开群组。您可以使用系统变量group_replication_unreachable_majority_timeout设置成员在与大多数群组成员失去联系后等待的秒数，然后退出群组。设置超时意味着您无需主动监视网络分区后处于少数派群组的服务器，并且可以避免由于不当干预而创建群组成员的两个版本导致的分裂脑情况。

当group_replication_unreachable_majority_timeout指定的超时时间到期时，已由该成员和少数派群组中的其他成员处理的所有待处理事务都将被回滚，并且该群组中的服务器将移至ERROR状态。您可以使用从 MySQL 8.0.16 开始提供的group_replication_autorejoin_tries系统变量，使成员在此时自动尝试重新加入群组。从 MySQL 8.0.21 开始，默认情况下激活此功能，并且成员将进行三次自动重新加入尝试。如果自动重新加入过程不成功或未尝试，则少数派成员将按照group_replication_exit_state_action指定的退出操作进行。

在决定是否设置不可达多数超时时，请考虑以下几点：

在对称群组中，例如具有两个或四个服务器的群组，如果两个分区包含相等数量的服务器，则两个群组都认为自己处于少数派并进入ERROR状态。在这种情况下，群组没有功能性分区。
尽管存在少数派群组，但由少数派群组处理的任何事务都会被接受，但由于少数服务器无法达到法定人数，这些事务被阻塞，直到在这些服务器上发出STOP GROUP_REPLICATION或达到不可达多数超时为止。
如果不设置不可达多数超时，则少数派群组中的服务器永远不会自动进入ERROR状态，您必须手动停止它们。
如果在检测到大多数丢失后在少数派群组的服务器上设置不可达多数超时，则不会产生任何影响。

如果您不使用group_replication_unreachable_majority_timeout系统变量，则在网络分区事件中进行操作发明的过程在第 20.7.8 节，“处理网络分区和失去法定人数”中描述。该过程涉及检查哪些服务器正在运行，并在必要时强制进行新的组成员资格。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure-rejoin.html

20.7.7.3 自动重新加入

group_replication_autorejoin_tries系统变量从 MySQL 8.0.16 开始提供，使被驱逐或达到不可达多数超时的成员尝试自动重新加入组。在 MySQL 8.0.20 之前，系统变量的值默认为 0，因此默认情况下不会激活自动重新加入。从 MySQL 8.0.21 开始，系统变量的值默认为 3，这意味着成员会自动尝试重新加入组，每次尝试之间间隔 5 分钟，最多尝试 3 次。

当未激活自动重新加入时，成员一旦恢复通信即接受其驱逐，并继续执行由group_replication_exit_state_action系统变量指定的操作。之后，需要手动干预才能将成员带回组中。如果您可以容忍可能出现过时读取的可能性，并希望最小化手动干预的需求，特别是在瞬时网络问题经常导致成员被驱逐的情况下，使用自动重新加入功能是合适的。

使用自动重新加入时，当成员被驱逐或达到不可达多数超时时，它会尝试重新加入（使用当前插件选项值），然后继续进行进一步的自动重新加入尝试，直到达到指定的尝试次数为止。在一次不成功的自动重新加入尝试后，成员在下一次尝试之前等待 5 分钟。自动重新加入尝试和它们之间的时间称为自动重新加入过程。如果在成员重新加入或停止之前耗尽了指定的尝试次数，则成员将执行由group_replication_exit_state_action系统变量指定的操作。

在自动重新加入尝试期间和之间，成员保持在超级只读模式，并在其复制组视图上显示ERROR状态。在此期间，成员不接受写入。但是，随着时间的推移，成员上的读取仍然可以进行，但随着时间的推移，读取变得越来越可能过时。如果您确实希望在自动重新加入过程中干预以使成员脱机，可以随时使用STOP GROUP_REPLICATION语句或关闭服务器来手动停止成员。如果您无法容忍任何时间段内可能出现过时读取的可能性，请将group_replication_autorejoin_tries系统变量设置为 0。

你可以使用性能模式监视自动重新加入过程。在自动重新加入过程进行时，性能模式表events_stages_current显示事件“正在进行自动重新加入过程”，显示到目前为止在此过程实例中尝试的重试次数（在WORK_COMPLETED字段中）。events_stages_summary_global_by_event_name表显示服务器实例启动自动重新加入过程的次数（在COUNT_STAR字段中）。events_stages_history_long表显示每个自动重新加入过程完成的时间（在TIMER_END字段中）。当成员重新加入复制组时，在组完成兼容性检查并接受其为成员之前，其状态可能显示为OFFLINE或ERROR。当成员正在赶上组的事务时，其状态为RECOVERING。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure-exit.html

20.7.7.4 退出操作

group_replication_exit_state_action系统变量，从 MySQL 8.0.12 和 MySQL 5.7.24 开始提供，指定了当成员由于错误或问题意外离开组时，Group Replication 应该执行的操作，以及在自动重新加入失败或不尝试重新加入时的操作。请注意，在被驱逐成员的情况下，成员在重新连接到组之前并不知道自己被驱逐，因此只有在成员成功重新连接或成员对自己产生怀疑并将自己驱逐时，才会执行指定的操作。

按影响顺序，退出操作如下：

如果READ_ONLY是退出操作，实例将通过将系统变量super_read_only设置为ON，将 MySQL 切换到超级只读模式。当成员处于超级只读模式时，客户端无法进行任何更新操作，即使他们拥有CONNECTION_ADMIN权限（或已弃用的SUPER权限）。然而，客户端仍然可以读取数据，由于不再进行更新，随着时间的推移，存在过时读取的可能性会增加。因此，您需要主动监视服务器以防止故障。从 MySQL 8.0.15 开始，这是默认的退出操作。在执行此退出操作后，成员的状态将在组的视图中显示为ERROR。
如果OFFLINE_MODE是退出操作，则通过将系统变量offline_mode设置为ON，实例将将 MySQL 切换到离线模式。当成员处于离线模式时，连接的客户端用户在下一次请求时将被断开连接，不再接受连接，但具有CONNECTION_ADMIN权限（或已弃用的SUPER权限）的客户端用户除外。Group Replication 还将系统变量super_read_only设置为ON，因此客户端无法进行任何更新，即使他们已经使用CONNECTION_ADMIN或SUPER权限连接。此退出操作阻止了更新和过时读取（除了具有上述权限的客户端用户进行读取），并使代理工具（如 MySQL Router）能够识别服务器不可用并重定向客户端连接。它还保持实例运行，以便管理员可以尝试解决问题而不关闭 MySQL。此退出操作从 MySQL 8.0.18 版本开始提供。在执行此退出操作后，成员的状态在组的视图中显示为ERROR（而不是OFFLINE，这意味着成员具有 Group Replication 功能，但当前不属于任何组）。
如果ABORT_SERVER是退出操作，则实例将关闭 MySQL。指示成员关闭自身可以防止所有过时读取和客户端更新，但这意味着 MySQL Server 实例不可用，必须重新启动，即使问题可以在不进行此步骤的情况下解决。此退出操作是从 MySQL 8.0.12 版本（添加系统变量时）到 MySQL 8.0.15 版本（含）的默认操作。在执行此退出操作后，成员将从组的视图中的服务器列表中删除。

请注意，无论设置了哪种退出操作，都需要操作员干预，因为已耗尽自动重新加入尝试（或从未有过）并已被组驱逐的前成员不允许重新加入而无需重新启动 Group Replication。退出操作仅影响客户端是否仍然可以在无法重新加入组的服务器上读取数据，以及服务器是否保持运行。

重要提示

如果在成员成功加入组之前发生故障，则不会执行group_replication_exit_state_action指定的退出操作。这种情况发生在本地配置检查期间发生故障，或者加入成员的配置与组的配置不匹配时。在这些情况下，super_read_only系统变量保持其原始值，服务器不会关闭 MySQL。为了确保当 Group Replication 未启动时服务器无法接受更新，我们建议在服务器启动时在配置文件中设置super_read_only=ON，Group Replication 在成功启动后将其更改为OFF。当服务器配置为在服务器启动时启动 Group Replication（group_replication_start_on_boot=ON）时，此保护措施尤为重要，但在使用START GROUP_REPLICATION命令手动启动 Group Replication 时也很有用。

如果成员成功加入组后发生故障，则执行指定的退出操作。以下情况会发生：

应用程序错误 - 复制应用程序中存在错误。此问题无法恢复。
无法进行分布式恢复 - 存在问题，导致 Group Replication 的分布式恢复过程（使用远程克隆操作和从二进制日志进行状态传输）无法完成。Group Replication 在适当的情况下会自动重试分布式恢复，但如果没有更多选项来完成该过程，则会停止。有关详细信息，请参见第 20.5.4.4 节，“分布式恢复的容错性”。
组配置更改错误 - 在使用函数进行组范围配置更改时发生错误，如第 20.5.1 节，“配置在线组”中所述。
主选举错误 - 在单主模式下为组选择新主成员时发生错误，如第 20.1.3.1 节，“单主模式”中所述。
无法访问的多数超时 - 成员与大多数组成员失去联系，因此处于少数，并且由 group_replication_unreachable_majority_timeout 系统变量设置的超时已经过期。
成员被组驱逐 - 对成员提出了怀疑，并且由 group_replication_member_expel_timeout 系统变量设置的任何超时已经过期，成员已恢复与组的通信并发现自己已被驱逐。
超出自动重新加入尝试次数 - group_replication_autorejoin_tries 系统变量被设置为指定在失去多数或被驱逐后的自动重新加入尝试次数，成员完成了这些尝试次数但未成功。

以下表格总结了每种情况下的失败场景和操作：

表 20.3 组复制失败情况下的退出操作

失败情况	使用 START GROUP_REPLICATION 启动组复制	使用 group_replication_start_on_boot =ON 启动组复制
成员未通过本地配置检查加入成员与组配置不匹配	super_read_only 和 offline_mode 未更改 MySQL 继续运行在启动时设置 super_read_only=ON 以防止更新	super_read_only 和 offline_mode 未更改 MySQL 继续运行在启动时设置 super_read_only=ON 以防止更新（重要）
应用程序错误在成员分布式恢复不可能组配置更改错误主要选举错误无法访问的多数超时成员被组驱逐超出自动重新加入尝试次数	super_read_only 设置为 ON 或 offline_mode 和 super_read_only 设置为 ON 或 MySQL 关闭	super_read_only 设置为 ON 或 offline_mode 和 super_read_only 设置为 ON 或 MySQL 关闭

20.7.8 处理网络分区和失去法定人数

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-network-partitioning.html

当需要复制发生的更改时，组需要达成共识。这适用于常规事务，但也适用于组成员更改和保持组一致性的某些内部消息。共识要求组成员中的大多数同意给定决定。当组成员的大多数丢失时，组无法继续进行并阻塞，因为它无法获得法定人数或法定人数。

当有多个非自愿故障导致大多数服务器突然从组中移除时，可能会丢失法定人数。例如，在 5 台服务器组中，如果其中有 3 台同时变得沉默，那么大多数就会受到影响，因此无法实现法定人数。事实上，剩下的两台无法确定其他 3 台服务器是否已崩溃，还是网络分区已将这两台孤立，因此组无法自动重新配置。

另一方面，如果服务器自愿退出组，它们会指示组应重新配置自身。实际上，这意味着要离开的服务器告诉其他人它要离开。这意味着其他成员可以正确地重新配置组，维护成员的一致性并重新计算法定人数。例如，在上述 5 台服务器的情况下，如果有 3 台同时离开，如果这 3 台离开的服务器依次警告组它们要离开，那么成员资格就能够从 5 调整到 2，并同时在此过程中确保法定人数。

注意

失去法定人数本身就是规划不良的副作用。根据预期故障数量规划组大小（无论这些故障是连续发生、同时发生还是零星发生）。

对于单主模式的组，主服务器可能有一些尚未在网络分区发生时其他成员上出现的事务。如果考虑将主服务器排除在新组之外，请注意这些事务可能会丢失。具有额外事务的成员无法重新加入组，尝试会导致错误消息，内容为此成员的已执行事务多于组中存在的事务。设置group_replication_unreachable_majority_timeout系统变量以避免此情况。

以下各节解释了如果系统以使组内服务器无法自动实现法定人数的方式分区应该怎么办。

检测分区

replication_group_members 性能模式表呈现了从该服务器的视角看到的当前视图中每台服务器的状态。大多数情况下，系统不会遇到分区，因此该表显示跨组中所有服务器一致的信息。换句话说，该表上每台服务器的状态在当前视图中得到了所有人的认可。然而，如果存在网络分区，并且丢失了法定人数，那么对于那些无法联系的服务器，该表将显示状态为 UNREACHABLE。这些信息由 Group Replication 内置的本地故障检测器导出。

图 20.14 失去法定人数

五个服务器实例，S1、S2、S3、S4 和 S5，部署为一个相互连接的稳定组。当其中三台服务器 S3、S4 和 S5 失效时，大多数失去，组无法在没有干预的情况下继续运行。

要理解这种类型的网络分区，以下部分描述了最初有 5 台服务器正确协作的情景，以及一旦只有 2 台服务器在线后组发生的变化。该情景在图中描述。

因此，假设有一个包含这 5 台服务器的组：

服务器 s1 的成员标识符为 199b2df7-4aaf-11e6-bb16-28b2bd168d07
服务器 s2 的成员标识符为 199bb88e-4aaf-11e6-babe-28b2bd168d07
服务器 s3 的成员标识符为 1999b9fb-4aaf-11e6-bb54-28b2bd168d07
服务器 s4 的成员标识符为 19ab72fc-4aaf-11e6-bb51-28b2bd168d07
服务器 s5 的成员标识符为 19b33846-4aaf-11e6-ba81-28b2bd168d07

最初，组运行良好，服务器之间愉快地进行通信。您可以通过登录 s1 并查看其 replication_group_members 性能模式表来验证这一点。例如：

mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+-------------+
| MEMBER_ID                            | MEMBER_STATE | MEMBER_ROLE |
+--------------------------------------+--------------+-------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE       | SECONDARY   |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       | PRIMARY     |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE       | SECONDARY   |
+--------------------------------------+--------------+-------------+

然而，片刻之后发生了灾难性故障，服务器 s3、s4 和 s5 意外停止运行。几秒钟后，再次查看 s1 上的 replication_group_members 表，显示它仍然在线，但其他几个成员不在线。事实上，如下所示，它们被标记为 UNREACHABLE。此外，系统无法重新配置自身以更改成员资格，因为大多数成员已经丢失。

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

表格显示，s1 现在处于一个没有办法继续进行的组中，因为大多数服务器无法访问。在这种特殊情况下，需要重置组成员列表以允许系统继续进行，这在本节中有解释。或者，您也可以选择停止 s1 和 s2 上的组复制（或完全停止 s1 和 s2），弄清楚 s3、s4 和 s5 发生了什么，然后重新启动组复制（或服务器）。

解除分区阻塞

组复制使您能够通过强制特定配置来重置组成员列表。例如，在上述情况中，只有 s1 和 s2 在线，您可以选择强制执行仅包含 s1 和 s2 的成员配置。这需要检查有关 s1 和 s2 的一些信息，然后使用 group_replication_force_members 变量。

图 20.15 强制执行新的成员配置

组中的三台服务器 S3、S4 和 S5 失败，因此失去了多数派，组无法继续进行。通过下文描述的干预，S1 和 S2 能够自行形成一个稳定的组。

假设您回到了只剩下 s1 和 s2 两台服务器的情况。服务器 s3、s4 和 s5 突然离开了组。为了让服务器 s1 和 s2 继续运行，您希望强制执行一个只包含 s1 和 s2 的成员配置。

警告

此过程使用 group_replication_force_members ，应被视为最后的补救措施。它必须极度小心使用，仅用于覆盖丧失法定人数的情况。如果被滥用，可能会导致人为的脑裂情况或完全阻塞整个系统。

在强制执行新的成员配置时，请确保任何要被强制退出组的服务器确实已经停止运行。在上述场景中，如果 s3、s4 和 s5 并非真正无法访问，而是在线的话，它们可能已经形成了自己的功能分区（它们是 5 台中的 3 台，因此拥有多数派）。在这种情况下，强制使用只包含 s1 和 s2 的组成员列表可能会导致人为的脑裂情况。因此，在强制执行新的成员配置之前，确保要排除的服务器确实已关闭，如果没有关闭，请在继续之前关闭它们。

警告

对于单主模式的组，主服务器可能有一些在网络分区时其他成员尚未存在的事务。如果您考虑将主服务器排除在新组之外，请注意这些事务可能会丢失。具有额外事务的成员无法重新加入组，尝试会导致错误消息为此成员的已执行事务多于组中存在的事务。设置group_replication_unreachable_majority_timeout系统变量以避免此情况。

请记住系统被阻塞，当前配置如下（由s1上的本地故障检测器感知）：

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

首先要做的是检查s1和s2的本地地址（组通信标识符）。登录到s1和s2，并按以下方式获取该信息。

mysql> SELECT @@group_replication_local_address;

一旦知道s1（127.0.0.1:10000）和s2（127.0.0.1:10001）的组通信地址，您可以在两个服务器中的一个上使用它来注入新的成员配置，从而覆盖已失去法定人数的现有配置。在s1上执行以下操作：

mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";

通过强制不同配置来解除组的阻塞。在此更改后，检查s1和s2上的replication_group_members以验证组成员身份。首先在s1上。

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

然后在s2上执行。

mysql> SELECT * FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

在使用group_replication_force_members系统变量成功强制新的组成员身份并解除组阻塞后，请确保清除该系统变量。为了发出START GROUP_REPLICATION语句，group_replication_force_members必须为空。

20.7.9 使用 Performance Schema 内存仪表化监控 Group Replication 内存使用情况

原文：dev.mysql.com/doc/refman/8.0/en/mysql-gr-memory-monitoring-ps-instruments.html

20.7.9.1 启用或禁用 Group Replication 仪表化

20.7.9.2 示例查询

从 MySQL 8.0.30 开始，Performance Schema 提供了用于监控 Group Replication 内存使用情况的仪表化。要查看可用的 Group Replication 仪表，执行以下查询：

mysql> SELECT NAME,ENABLED FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/group_rpl/%';
+-------------------------------------------------------------------+---------+
| NAME                                                              | ENABLED |
+-------------------------------------------------------------------+---------+
| memory/group_rpl/write_set_encoded                                | YES     |
| memory/group_rpl/certification_data                               | YES     |
| memory/group_rpl/certification_data_gc                            | YES     |
| memory/group_rpl/certification_info                               | YES     |
| memory/group_rpl/transaction_data                                 | YES     |
| memory/group_rpl/sql_service_command_data                         | YES     |
| memory/group_rpl/mysql_thread_queued_task                         | YES     |
| memory/group_rpl/message_service_queue                            | YES     |
| memory/group_rpl/message_service_received_message                 | YES     |
| memory/group_rpl/group_member_info                                | YES     |
| memory/group_rpl/consistent_members_that_must_prepare_transaction | YES     |
| memory/group_rpl/consistent_transactions                          | YES     |
| memory/group_rpl/consistent_transactions_prepared                 | YES     |
| memory/group_rpl/consistent_transactions_waiting                  | YES     |
| memory/group_rpl/consistent_transactions_delayed_view_change      | YES     |
| memory/group_rpl/GCS_XCom::xcom_cache                             | YES     |
| memory/group_rpl/Gcs_message_data::m_buffer                       | YES     |
+-------------------------------------------------------------------+---------+

有关 Performance Schema 内存仪表化和事件的更多信息，请参阅第 29.12.20.10 节，“内存摘要表”。

Performance Schema Group Replication 为 Group Replication 的内存分配提供仪表化。

memory/group_rpl/ Performance Schema 仪表化在 8.0.30 中进行了更新，以扩展对 Group Replication 内存使用情况的监控。memory/group_rpl/ 包含以下仪表：

write_set_encoded: 在广播到组成员之前对写入集进行编码分配的内存。
Gcs_message_data::m_buffer: 为发送到网络的事务数据负载分配的内存。
certification_data: 为传入事务的认证分配的内存。
certification_data_gc: 为每个成员发送的 GTID_EXECUTED 进行垃圾回收分配的内存。
certification_info: 为解决并发事务之间冲突分配的认证信息存储内存。
transaction_data: 为排队等待插件管道的传入事务分配的内存。
message_service_received_message: 为从 Group Replication 传递消息服务接收消息分配的内存。
sql_service_command_data: 为处理内部 SQL 服务命令队列分配的内存。
mysql_thread_queued_task: 当将 MySQL 线程相关任务添加到处理队列时分配的内存。
message_service_queue: 为 Group Replication 传递消息服务的排队消息分配的内存。
GCS_XCom::xcom_cache: 为组成员之间作为共识协议的一部分交换的消息和元数据分配的 XCOM 缓存内存。
consistent_members_that_must_prepare_transaction: 为保存为 Group Replication 事务一致性保证准备事务的成员列表分配的内存。
consistent_transactions: 为保存事务和必须为 Group Replication 事务一致性保证准备该事务的成员列表分配的内存。
consistent_transactions_prepared: 为保存为 Group Replication 事务一致性保证准备的事务信息列表分配的内存。
consistent_transactions_waiting：用于保存在处理具有AFTER和BEFORE_AND_AFTER一致性的准备事务之前的事务列表信息的内存分配。
consistent_transactions_delayed_view_change：用于保存由于准备一致性事务等待准备确认而延迟的视图更改事件（view_change_log_event）列表的内存分配。
group_member_info：用于保存组成员属性的内存分配。属性如主机名、端口、成员权重和角色等。

memory/sql/ 分组中的以下工具也用于监视组复制内存：

Log_event：用于将事务数据编码为二进制日志格式的内存分配；这是组复制传输数据的相同格式。
write_set_extraction：在提交之前为事务生成的写入集分配的内存。
Gtid_set::to_string：用于存储 GTID 集合的字符串表示的内存分配。
Gtid_set::Interval_chunk：用于存储 GTID 对象的内存分配。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-gr-memory-monitoring-ps-instruments-enable.html

20.7.9.1 启用或禁用组复制仪器

要从命令行启用所有组复制仪器，请在您选择的 SQL 客户端中运行以下命令：

 UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' 
        WHERE NAME LIKE 'memory/group_rpl/%';

要从命令行禁用所有组复制仪器，请在您选择的 SQL 客户端中运行以下命令：

 UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' 
        WHERE NAME LIKE 'memory/group_rpl/%';

要在服务器启动时启用所有组复制仪器，请将以下内容添加到您的选项文件中：

 [mysqld]
 performance-schema-instrument='memory/group_rpl/%=ON'

要在服务器启动时禁用所有组复制仪器，请将以下内容添加到您的选项文件中：

 [mysqld]
 performance-schema-instrument='memory/group_rpl/%=OFF'

要启用或禁用该组中的单个仪器，请用该仪器的全名替换通配符（%）。

欲了解更多信息，请参阅 Section 29.3, “性能模式启动配置”和 Section 29.4, “性能模式运行时配置”。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-gr-memory-monitoring-ps-sample-queries.html

20.7.9.2 示例查询

本节描述了使用工具和事件监视组复制内存使用情况的示例查询。这些查询从memory_summary_global_by_event_name表中检索数据。

内存数据可以查询单个事件，例如：

SELECT * FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME = 'memory/group_rpl/write_set_encoded'\G

*************************** 1\. row ***************************
                  EVENT_NAME: memory/group_rpl/write_set_encoded
                 COUNT_ALLOC: 1
                  COUNT_FREE: 0
   SUM_NUMBER_OF_BYTES_ALLOC: 45
    SUM_NUMBER_OF_BYTES_FREE: 0
              LOW_COUNT_USED: 0
          CURRENT_COUNT_USED: 1
             HIGH_COUNT_USED: 1
    LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 45
   HIGH_NUMBER_OF_BYTES_USED: 45

更多关于列的信息，请参阅第 29.12.20.10 节，“内存摘要表”。

您还可以定义查询，对各种事件求和，以提供特定内存使用领域的概述。

下面描述了以下示例：

用于捕获事务的内存
用于广播事务的内存
组复制中的总内存使用量
认证中使用的内存
认证中使用的内存
复制管道中使用的内存
一致性中使用的内存
交付消息服务中使用的内存
用于广播和接收事务的内存

记忆用于捕获事务

用于捕获用户事务的内存分配是write_set_encoded、write_set_extraction和Log_event事件值的总和。例如：

 mysql> SELECT * FROM (
                   SELECT
                     (CASE
                        WHEN EVENT_NAME LIKE 'memory/group_rpl/write_set_encoded'
                        THEN 'memory/group_rpl/memory_gr'
                        WHEN EVENT_NAME = 'memory/sql/write_set_extraction'
                        THEN 'memory/group_rpl/memory_gr'
                        WHEN EVENT_NAME = 'memory/sql/Log_event'
                        THEN 'memory/group_rpl/memory_gr'
                        ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                   SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                   SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                   SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                   SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                   SUM(HIGH_NUMBER_OF_BYTES_USED)
                 FROM performance_schema.memory_summary_global_by_event_name
                 GROUP BY (CASE
                              WHEN EVENT_NAME LIKE 'memory/group_rpl/write_set_encoded'
                              THEN 'memory/group_rpl/memory_gr'
                              WHEN EVENT_NAME = 'memory/sql/write_set_extraction'
                              THEN 'memory/group_rpl/memory_gr'
                              WHEN EVENT_NAME = 'memory/sql/Log_event'
                              THEN 'memory/group_rpl/memory_gr'
                              ELSE 'memory_gr_rest'
                            END)
      ) f
      WHERE f.EVENT_NAME != 'memory_gr_rest'
      *************************** 1\. row ***************************
                             EVENT_NAME: memory/group_rpl/memory_gr
                       SUM(COUNT_ALLOC): 127
                        SUM(COUNT_FREE): 117
         SUM(SUM_NUMBER_OF_BYTES_ALLOC): 54808
          SUM(SUM_NUMBER_OF_BYTES_FREE): 52051
                    SUM(LOW_COUNT_USED): 0
                SUM(CURRENT_COUNT_USED): 10
                   SUM(HIGH_COUNT_USED): 35
          SUM(LOW_NUMBER_OF_BYTES_USED): 0
      SUM(CURRENT_NUMBER_OF_BYTES_USED): 2757
         SUM(HIGH_NUMBER_OF_BYTES_USED): 15630

记忆用于广播事务

用于广播事务的内存分配是Gcs_message_data::m_buffer、transaction_data和GCS_XCom::xcom_cache事件值的总和。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME =  'memory/group_rpl/Gcs_message_data::m_buffer'
                       THEN 'memory/group_rpl/memory_gr'
                       WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
                       THEN 'memory/group_rpl/memory_gr'
                       WHEN EVENT_NAME = 'memory/group_rpl/transaction_data'
                       THEN 'memory/group_rpl/memory_gr'
                       ELSE 'memory_gr_rest'
                    END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                    SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                    SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                    SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                    SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                    SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME =  'memory/group_rpl/Gcs_message_data::m_buffer'
                              THEN 'memory/group_rpl/memory_gr'
                              WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
                              THEN 'memory/group_rpl/memory_gr'
                              WHEN EVENT_NAME = 'memory/group_rpl/transaction_data'
                              THEN 'memory/group_rpl/memory_gr'
                              ELSE 'memory_gr_rest'
                            END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                              EVENT_NAME: memory/group_rpl/memory_gr
                        SUM(COUNT_ALLOC): 84
                         SUM(COUNT_FREE): 31
          SUM(SUM_NUMBER_OF_BYTES_ALLOC): 1072324
           SUM(SUM_NUMBER_OF_BYTES_FREE): 7149
                     SUM(LOW_COUNT_USED): 0
                 SUM(CURRENT_COUNT_USED): 53
                    SUM(HIGH_COUNT_USED): 59
           SUM(LOW_NUMBER_OF_BYTES_USED): 0
       SUM(CURRENT_NUMBER_OF_BYTES_USED): 1065175
          SUM(HIGH_NUMBER_OF_BYTES_USED): 1065809

在组复制中使用的总内存

用于发送和接收事务、认证和所有其他主要进程的内存分配。通过查询memory/group_rpl/组的所有事件来计算。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME LIKE 'memory/group_rpl/%'
                       THEN 'memory/group_rpl/memory_gr'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                     SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                     SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                     SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                     SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                     SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME LIKE 'memory/group_rpl/%'
                              THEN 'memory/group_rpl/memory_gr'
                              ELSE 'memory_gr_rest'
                            END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                              EVENT_NAME: memory/group_rpl/memory_gr
                        SUM(COUNT_ALLOC): 190
                         SUM(COUNT_FREE): 127
          SUM(SUM_NUMBER_OF_BYTES_ALLOC): 1096370
           SUM(SUM_NUMBER_OF_BYTES_FREE): 28675
                     SUM(LOW_COUNT_USED): 0
                 SUM(CURRENT_COUNT_USED): 63
                    SUM(HIGH_COUNT_USED): 77
           SUM(LOW_NUMBER_OF_BYTES_USED): 0
       SUM(CURRENT_NUMBER_OF_BYTES_USED): 1067695
          SUM(HIGH_NUMBER_OF_BYTES_USED): 1069255

认证中使用的内存

认证过程中的内存分配是certification_data、certification_data_gc和certification_info事件值的总和。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME = 'memory/group_rpl/certification_data'
                       THEN 'memory/group_rpl/certification'
                       WHEN EVENT_NAME = 'memory/group_rpl/certification_data_gc'
                       THEN 'memory/group_rpl/certification'
                       WHEN EVENT_NAME = 'memory/group_rpl/certification_info'
                       THEN 'memory/group_rpl/certification'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                     SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                     SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                     SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                     SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                     SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME = 'memory/group_rpl/certification_data'
                              THEN 'memory/group_rpl/certification'
                              WHEN EVENT_NAME = 'memory/group_rpl/certification_data_gc'
                              THEN 'memory/group_rpl/certification'
                              WHEN EVENT_NAME = 'memory/group_rpl/certification_info'
                              THEN 'memory/group_rpl/certification'
                              ELSE 'memory_gr_rest'
                           END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                              EVENT_NAME: memory/group_rpl/certification
                        SUM(COUNT_ALLOC): 80
                         SUM(COUNT_FREE): 80
          SUM(SUM_NUMBER_OF_BYTES_ALLOC): 9442
           SUM(SUM_NUMBER_OF_BYTES_FREE): 9442
                     SUM(LOW_COUNT_USED): 0
                 SUM(CURRENT_COUNT_USED): 0
                    SUM(HIGH_COUNT_USED): 66
           SUM(LOW_NUMBER_OF_BYTES_USED): 0
       SUM(CURRENT_NUMBER_OF_BYTES_USED): 0
          SUM(HIGH_NUMBER_OF_BYTES_USED): 6561

复制管道中使用的内存

复制管道的内存分配是certification_data和transaction_data事件值的总和。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME LIKE 'memory/group_rpl/certification_data'
                       THEN 'memory/group_rpl/pipeline'
                       WHEN EVENT_NAME LIKE 'memory/group_rpl/transaction_data'
                       THEN 'memory/group_rpl/pipeline'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                     SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                     SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                     SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                     SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                     SUM(HIGH_NUMBER_OF_BYTES_USED)
                   FROM performance_schema.memory_summary_global_by_event_name
                   GROUP BY (CASE
                              WHEN EVENT_NAME LIKE 'memory/group_rpl/certification_data'
                              THEN 'memory/group_rpl/pipeline'
                              WHEN EVENT_NAME LIKE 'memory/group_rpl/transaction_data'
                              THEN 'memory/group_rpl/pipeline'
                              ELSE 'memory_gr_rest'
                            END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                         EVENT_NAME: memory/group_rpl/pipeline
                        COUNT_ALLOC: 17
                         COUNT_FREE: 13
          SUM_NUMBER_OF_BYTES_ALLOC: 2483
           SUM_NUMBER_OF_BYTES_FREE: 1668
                     LOW_COUNT_USED: 0
                 CURRENT_COUNT_USED: 4
                    HIGH_COUNT_USED: 4
           LOW_NUMBER_OF_BYTES_USED: 0
       CURRENT_NUMBER_OF_BYTES_USED: 815
          HIGH_NUMBER_OF_BYTES_USED: 815

一致性中使用的内存

事务一致性保证的内存分配是consistent_members_that_must_prepare_transaction、consistent_transactions、consistent_transactions_prepared、consistent_transactions_waiting和consistent_transactions_delayed_view_change事件值的总和。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_members_that_must_prepare_transaction'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_prepared'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_waiting'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_delayed_view_change'
                       THEN 'memory/group_rpl/consistency'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                    SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                    SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                    SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                    SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                    SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_members_that_must_prepare_transaction'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_prepared'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_waiting'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_delayed_view_change'
                              THEN 'memory/group_rpl/consistency'
                              ELSE 'memory_gr_rest'
                            END)
      ) f
      WHERE f.EVENT_NAME != 'memory_gr_rest'\G
      *************************** 1\. row ***************************
                        EVENT_NAME: memory/group_rpl/consistency
                       COUNT_ALLOC: 16
                        COUNT_FREE: 6
         SUM_NUMBER_OF_BYTES_ALLOC: 1464
          SUM_NUMBER_OF_BYTES_FREE: 528
                    LOW_COUNT_USED: 0
                CURRENT_COUNT_USED: 10
                   HIGH_COUNT_USED: 11
          LOW_NUMBER_OF_BYTES_USED: 0
      CURRENT_NUMBER_OF_BYTES_USED: 936
         HIGH_NUMBER_OF_BYTES_USED: 1024

交付消息服务中使用的内存

注意

此仪表适用于接收的数据，而不是发送的数据。

组复制交付消息服务的内存分配是message_service_received_message和message_service_queue事件值的总和。例如：

 mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME = 'memory/group_rpl/message_service_received_message'
                       THEN 'memory/group_rpl/message_service'
                       WHEN EVENT_NAME = 'memory/group_rpl/message_service_queue'
                       THEN 'memory/group_rpl/message_service'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                    SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                    SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                    SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                    SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                    SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME = 'memory/group_rpl/message_service_received_message'
                              THEN 'memory/group_rpl/message_service'
                              WHEN EVENT_NAME = 'memory/group_rpl/message_service_queue'
                              THEN 'memory/group_rpl/message_service'
                              ELSE 'memory_gr_rest'
                            END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                         EVENT_NAME: memory/group_rpl/message_service
                        COUNT_ALLOC: 2
                         COUNT_FREE: 0
          SUM_NUMBER_OF_BYTES_ALLOC: 1048664
           SUM_NUMBER_OF_BYTES_FREE: 0
                     LOW_COUNT_USED: 0
                 CURRENT_COUNT_USED: 2
                    HIGH_COUNT_USED: 2
           LOW_NUMBER_OF_BYTES_USED: 0
       CURRENT_NUMBER_OF_BYTES_USED: 1048664
          HIGH_NUMBER_OF_BYTES_USED: 1048664

用于广播和接收事务的内存

用于广播和接收网络中事务的内存分配是wGcs_message_data::m_buffer和GCS_XCom::xcom_cache事件值的总和。例如：

mysql> SELECT * FROM (
         SELECT
           (CASE
              WHEN EVENT_NAME = 'memory/group_rpl/Gcs_message_data::m_buffer'
              THEN 'memory/group_rpl/memory_gr'
              WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
              THEN 'memory/group_rpl/memory_gr'
              ELSE 'memory_gr_rest'
            END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
           SUM(SUM_NUMBER_OF_BYTES_ALLOC),
           SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
           SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
           SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
           SUM(HIGH_NUMBER_OF_BYTES_USED)
         FROM performance_schema.memory_summary_global_by_event_name
         GROUP BY (CASE
                     WHEN EVENT_NAME = 'memory/group_rpl/Gcs_message_data::m_buffer'
                     THEN 'memory/group_rpl/memory_gr'
                     WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
                     THEN 'memory/group_rpl/memory_gr'
                     ELSE 'memory_gr_rest'
                   END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                              EVENT_NAME: memory/group_rpl/memory_gr
                        SUM(COUNT_ALLOC): 73
                         SUM(COUNT_FREE): 20
          SUM(SUM_NUMBER_OF_BYTES_ALLOC): 1070845
           SUM(SUM_NUMBER_OF_BYTES_FREE): 5670
                     SUM(LOW_COUNT_USED): 0
                 SUM(CURRENT_COUNT_USED): 53
                    SUM(HIGH_COUNT_USED): 56
           SUM(LOW_NUMBER_OF_BYTES_USED): 0
       SUM(CURRENT_NUMBER_OF_BYTES_USED): 1065175
          SUM(HIGH_NUMBER_OF_BYTES_USED): 1065175

20.8 升级群组复制

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade.html

20.8.1 在群组中合并不同成员版本

20.8.2 群组复制离线升级

20.8.3 群组复制在线升级

本节解释了如何升级群组复制设置。升级群组成员的基本过程与升级独立实例的过程相同，请参阅 Chapter 3, Upgrading MySQL了解实际的升级过程和可用的类型。在原地升级和逻辑升级之间的选择取决于群组中存储的数据量。通常，原地升级更快，因此建议使用。您还应该参考 Section 19.5.3, “Upgrading a Replication Topology”。

在升级在线群组的过程中，为了最大化可用性，您可能需要在同一时间运行具有不同 MySQL 服务器版本的成员。群组复制包括兼容性策略，使您能够在升级过程中安全地将运行不同 MySQL 版本的成员合并到同一群组中。根据您的群组，这些策略的影响可能会影响您应该升级群组成员的顺序。有关详细信息，请参见 Section 20.8.1, “Combining Different Member Versions in a Group”。

如果您的群组可以完全脱机，请参见 Section 20.8.2, “群组复制离线升级”。如果您的群组需要保持在线，这在生产部署中很常见，请参见 Section 20.8.3, “群组复制在线升级”，了解升级群组的不同方法以最小化停机时间。

20.8.1 在组中组合不同的成员版本

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-combining-versions.html

20.8.1.1 升级期间的成员版本

20.8.1.2 组复制通信协议版本

组复制的版本与捆绑有 Group Replication 插件的 MySQL 服务器版本相对应。例如，如果一个成员运行 MySQL 5.7.26，则 Group Replication 插件的版本就是这个版本。要检查组成员上的 MySQL 服务器版本，请发出：

SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com |	   3306     |   8.0.13	     |
+-------------+-------------+----------------+

有关理解 MySQL 服务器版本和选择版本的指导，请参见 Section 2.1.2，“选择要安装的 MySQL 版本和发行版”。

为了获得最佳兼容性和性能，组中的所有成员应该运行相同版本的 MySQL 服务器，因此也应该运行相同版本的组复制。然而，在在线升级组的过程中，为了最大化可用性，您可能需要同时运行具有不同 MySQL 服务器版本的成员。根据 MySQL 版本之间的更改，您可能会在这种情况下遇到不兼容性。例如，如果在主要版本之间已弃用某个功能，则将版本组合到组中可能导致依赖于已弃用功能的成员失败。相反，如果在组中有运行较新 MySQL 版本的读写成员时向运行较旧 MySQL 版本的成员写入数据，可能会导致缺少较新版本引入的功能的成员出现问题。

为了防止这些问题，组复制包括兼容性策略，使您能够安全地将运行不同 MySQL 版本的成员组合到同一组中。成员应用这些策略来决定是否正常加入组，或以只读模式加入，或不加入组，具体取决于哪种选择能够确保加入成员和现有组成员的安全运行。在升级场景中，每个服务器必须离开组，进行升级，然后使用新的服务器版本重新加入组。此时，成员将应用其新服务器版本的策略，这可能已经与其最初加入组时应用的策略不同。

作为管理员，你可以通过配置服务器并发出 START GROUP_REPLICATION 语句，指示任何服务器尝试加入任何组。加入组或不加入组，或以只读模式加入组的决定由加入成员自己在尝试将其添加到组后进行，并由其自行实施。加入成员接收当前组成员的 MySQL 服务器版本信息，评估自己与这些成员的兼容性，并应用其自己 MySQL 服务器版本中使用的策略（而不是现有成员使用的策略）来决定是否兼容。

加入组时，加入成员应用的兼容性策略如下：

如果成员运行的 MySQL 服务器版本低于现有组成员运行的最低版本，则该成员不加入组。
如果成员运行的 MySQL 服务器版本与现有组成员运行的最低版本相同，则该成员正常加入组。
如果成员运行的 MySQL 服务器版本高于现有组成员运行的最低版本，则该成员加入组但保持只读模式。这种行为仅在组以多主模式运行时才有区别，因为在以单主模式运行的组中，新添加的成员默认始终为只读模式。

运行 MySQL 8.0.17 或更高版本的成员在检查兼容性时考虑发布的补丁版本。运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7 的成员只考虑主要版本。例如，如果你有一个所有成员都运行 MySQL 版本 8.0.13 的组：

运行 MySQL 版本 5.7 的成员无法加入。
运行 MySQL 8.0.16 的成员正常加入（因为它考虑主要版本）。
运行 MySQL 8.0.17 的成员加入但保持只读模式（因为它考虑了补丁版本）。

请注意，运行 MySQL 5.7.27 之前版本的加入成员会检查所有组成员，以确定自己的 MySQL 服务器主要版本是否较低。因此，对于任何成员运行 MySQL 8.0 版本的组，它们将无法通过此检查，即使该组已经有其他运行 MySQL 5.7 的成员。从 MySQL 5.7.27 开始，加入成员只会检查运行最低主要版本的组成员，因此它们可以加入一个混合版本组，其中存在其他 MySQL 5.7 服务器。

在一个多主模式组中，成员使用不同的 MySQL Server 版本，Group Replication 会自动管理运行 MySQL 8.0.17 或更高版本的成员的读写和只读状态。如果一个成员离开组，那些运行当前最低版本的成员会自动设置为读写模式。当你将原本以单主模式运行的组改为多主模式时，使用group_replication_switch_to_multi_primary_mode()函数，Group Replication 会自动将成员设置为正确的模式。如果某些成员运行的 MySQL 服务器版本高于组中最低版本，那么它们会自动被设置为只读模式，而运行最低版本的成员会被设置为读写模式。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-compatibility-upgrade.html

20.8.1.1 升级过程中的成员版本

在在线升级过程中，如果组处于单主模式，则所有当前未脱机升级的服务器将像以前一样运行。每当需要时，组会选举新的主服务器，遵循第 20.1.3.1 节“单主模式”中描述的选举策略。请注意，如果您要求主服务器在整个过程中保持不变（除非它本身正在升级），则必须首先将所有次要服务器升级到高于或等于目标主服务器版本的版本，然后最后升级主服务器。主服务器不能保持为主服务器，除非它正在运行组中最低的 MySQL 服务器版本。主服务器升级后，您可以使用group_replication_set_as_primary()函数重新任命它为主服务器。

如果组处于多主模式，则在升级过程中可用于执行写操作的在线成员较少，因为升级后的成员在升级后以只读模式加入。从 MySQL 8.0.17 开始，这适用于补丁版本之间的升级，对于较低版本，这仅适用于主要版本之间的升级。当所有成员都升级到相同版本时，从 MySQL 8.0.17 开始，它们都会自动切换回读写模式。对于早期版本，您必须在每个应在升级后充当主服务器的成员上手动将super_read_only设置为OFF。

为了处理问题情况，例如如果您必须回滚升级或在紧急情况下增加组的额外容量，可以允许成员加入在线组，尽管其运行的 MySQL 服务器版本低于其他组成员使用的最低版本。在这种情况下，可以使用 Group Replication 系统变量group_replication_allow_local_lower_version_join来覆盖正常的兼容性策略。

重要提示

将group_replication_allow_local_lower_version_join设置为ON并不使新成员与组兼容；这样做允许其加入组，而没有任何防范措施来防止现有成员的不兼容行为。因此，这必须仅在特定情况下小心使用，并且您必须采取额外预防措施，以避免新成员由于正常组活动而失败。有关此变量的更多信息，请参阅其描述。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-compatibility-communication.html

20.8.1.2 Group Replication 通信协议版本

复制组使用的 Group Replication 通信协议版本可能与成员的 MySQL Server 版本不同。要检查组的通信协议版本，请在任何成员上发出以下语句：

SELECT group_replication_get_communication_protocol();

返回值显示了可以加入此组并使用组通信协议的最旧 MySQL Server 版本。从 MySQL 5.7.14 版本开始允许消息压缩，而从 MySQL 8.0.16 版本开始还允许消息分段。请注意，group_replication_get_communication_protocol() 函数返回组支持的最低 MySQL 版本，这可能与传递给 group_replication_set_communication_protocol() 函数的版本号不同，并且可能与在使用该函数的成员上安装的 MySQL Server 版本不同。

当您将复制组的所有成员升级到新的 MySQL Server 版本时，Group Replication 通信协议版本不会自动升级，以防仍然需要允许早期版本的成员加入。如果您不需要支持旧版本成员，并希望允许升级后的成员使用任何新增的通信功能，在升级后使用 group_replication_set_communication_protocol() 函数升级通信协议，指定您已将成员升级到的新 MySQL Server 版本。有关更多信息，请参见 Section 20.5.1.4, “Setting a Group’s Communication Protocol Version”。

20.8.2 Group Replication 离线升级

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-offline-upgrade.html

要执行 Group Replication 组的离线升级，您需要将每个成员从组中移除，对成员进行升级，然后像往常一样重新启动组。在多主组中，您可以以任何顺序关闭成员。在单主组中，首先关闭每个次要成员，然后最后关闭主要成员。参见第 20.8.3.2 节，“升级 Group Replication 成员”了解如何从组中移除成员并关闭 MySQL。

一旦组离线，升级所有成员。参见第三章，升级 MySQL了解如何执行升级。当所有成员都升级完毕后，重新启动成员。

如果在组离线时升级所有复制组成员，然后重新启动组，成员将使用新版本的 Group Replication 通信协议版本加入，因此该版本将成为组的通信协议版本。如果您有要求允许较早版本的成员加入，您可以使用group_replication_set_communication_protocol()函数降级通信协议版本，指定具有最旧安装服务器版本的潜在组成员的 MySQL 服务器版本。

20.8.3 集群复制在线升级

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade.html

20.8.3.1 在线升级考虑事项

20.8.3.2 升级集群复制成员

20.8.3.3 集群复制在线升级方法

20.8.3.4 使用mysqlbackup进行集群复制升级

当您有一个正在运行的集群需要升级，但您需要保持集群在线以提供应用程序服务时，您需要考虑升级的方法。本节描述了在线升级涉及的不同元素，以及如何升级您的集群的各种方法。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-considerations.html

20.8.3.1 在线升级注意事项

在升级在线组时，您应考虑以下几点：

无论您如何升级您的组，重要的是在他们准备重新加入组之前禁用对组成员的任何写入。
当成员停止时，super_read_only 变量会自动设置为打开，但此更改不会持久保存。
当 MySQL 5.7.22 或 MySQL 8.0.11 尝试加入运行 MySQL 5.7.21 或更低版本的组时，它无法加入该组，因为 MySQL 5.7.21 不会发送其 lower_case_table_names 的值。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrading-member.html

20.8.3.2 升级组复制成员

本节解释了升级组成员所需的步骤。此过程是第 20.8.3.3 节“组复制在线升级方法”描述的方法的一部分。升级组成员的过程对所有方法都是通用的，并首先进行解释。加入升级成员的方式可能取决于您正在遵循的方法，以及诸如组是在单主还是多主模式下运行等其他因素。您如何升级服务器实例，无论是使用就地升级还是预置方法，都不会影响此处描述的方法。

升级成员的过程包括将其从组中移除，按照您选择的升级成员的方法进行升级，然后将升级后的成员重新加入组。在单主组中升级成员的推荐顺序是先升级所有次要成员，然后最后再升级主要成员。如果在次要成员之前升级主要成员，则会选择使用旧版 MySQL 版本的新主要成员，但这一步是不必要的。

要升级组的成员：

连接客户端到组成员并发出STOP GROUP_REPLICATION。在继续之前，请通过监视replication_group_members表确保成员的状态为OFFLINE。
禁用自动启动组复制，以便您可以安全地在升级后连接到成员并进行配置，而不会在设置group_replication_start_on_boot=0后重新加入组。重要如果升级的成员设置了group_replication_start_on_boot=1，那么在你执行 MySQL 升级过程之前，它可能会重新加入组，并可能导致问题。例如，如果升级失败并且服务器再次重启，那么可能会尝试加入组的是一个可能损坏的服务器。
停止成员，例如使用mysqladmin shutdown或SHUTDOWN语句。组中的其他成员继续运行。
使用就地或配置方法升级成员。有关详细信息，请参见第三章，升级 MySQL。在重新启动升级后的成员时，因为group_replication_start_on_boot设置为 0，Group Replication 不会在实例上启动，因此它不会重新加入组。
一旦在成员上执行了 MySQL 升级过程，必须将group_replication_start_on_boot设置为 1，以确保在重新启动后正确启动 Group Replication。重新启动成员。
连接到升级后的成员并发出START GROUP_REPLICATION。这将重新加入成员到组中。升级服务器上已经存在 Group Replication 元数据，因此通常不需要重新配置 Group Replication。服务器必须赶上在其离线时组处理的任何事务。一旦赶上组，它就成为组的在线成员。注意升级服务器所需的时间越长，该成员离线的时间就越长，因此在重新添加到组中时，服务器需要花费更多时间来赶上。

当升级后的成员加入任何运行较早 MySQL 服务器版本的组时，升级后的成员会以super_read_only=on加入。这确保在所有成员都运行新版本之前，不会向升级后的成员进行写入。在多主模式组中，当升级成功完成并且组准备好处理事务时，打算作为可写主节点的成员必须设置为读写模式。从 MySQL 8.0.17 开始，当组的所有成员都升级到相同版本时，它们都会自动切换回读写模式。对于早期版本，您必须手动将每个成员设置为读写模式。连接到每个成员并发出：

SET GLOBAL super_read_only=OFF;

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-methods.html

20.8.3.3 Group Replication Online Upgrade Methods

选择以下升级 Group Replication 组的方法之一：

滚动式组内升级

只要运行较新版本的服务器不会在仍有较旧版本的服务器的情况下向组生成工作负载，此方法就受支持。换句话说，只有运行较新版本的服务器可以作为辅助服务器加入组。在此方法中，只有一个组，每个服务器实例都会从组中移除，升级，然后重新加入组。

此方法非常适用于单主组。当组以单主模式运行时，如果您要求主服务器在整个过程中保持不变（除非正在升级自身），则应将其作为最后一个升级的成员。主服务器必须在组中运行最低版本的 MySQL 服务器版本才能保持为主服务器。主服务器升级后，您可以使用group_replication_set_as_primary()函数将其重新指定为主服务器。如果您不在意哪个成员是主服务器，那么成员可以以任何顺序进行升级。组在必要时从运行最低 MySQL 服务器版本的成员中选举新的主服务器，遵循第 20.1.3.1 节，“单主模式”中描述的选举策略。

对于以多主模式运行的组，在组内滚动升级期间，主服务器数量会减少，导致写入可用性降低。这是因为如果成员在组运行时加入组，而其运行的 MySQL 服务器版本高于现有组成员运行的最低版本，则它会自动保持为只读模式（super_read_only=ON）。请注意，运行 MySQL 8.0.17 或更高版本的成员在检查时会考虑发布的补丁版本，但运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7 的成员只会考虑主要版本。当所有成员升级到相同版本后，从 MySQL 8.0.17 开始，它们会自动恢复为读写模式。对于早期版本，您必须在每个成员上手动设置super_read_only=OFF，以便在升级后作为主服务器运行。

有关组中版本兼容性的完整信息以及这如何影响升级过程中组的行为，请参阅第 20.8.1 节，“组中不同成员版本的组合”。

滚动式迁移升级

在这种方法中，您将从组中移除成员，升级它们，然后使用升级后的成员创建第二组。对于在多主模式下运行的组，在此过程中主节点的数量会减少，导致写入可用性降低。这不会影响在单主模式下运行的组。

因为在升级成员时运行较旧版本的组在线，所以需要运行较新版本的组赶上在升级成员时执行的任何事务。因此，新组中的一个服务器被配置为较旧组的主节点的副本。这确保新组赶上较旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此它在异步源-副本复制的相同假设和要求下受支持，参见 Chapter 19, 复制。对于在单主模式下运行的组，向旧组的异步复制连接必须发送数据到新组的主节点，对于多主组，异步复制通道可以连接到任何主节点。

过程如下：

逐个从运行较旧服务器版本的原始组中移除成员，参见 Section 20.8.3.2, “升级组复制成员”
升级运行在成员上的服务器版本，参见 Chapter 3, 升级 MySQL。您可以选择进行就地升级或预置升级的方法。
创建一个具有升级成员的新组，参见 Chapter 20, 组复制。在这种情况下，您需要在每个成员上配置一个新组名称（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加其余的升级成员。
在旧组和新组之间建立一个异步复制通道，参见 Section 19.1.3.4, “使用 GTIDs 设置复制”。将较旧的主节点配置为异步复制源服务器，将新组成员配置为基于 GTID 的副本。

在将应用程序重定向到新组之前，您必须确保新组具有合适数量的成员，例如使组能够处理成员的故障。执行SELECT * FROM performance_schema.replication_group_members并比较初始组大小和新组大小。等到所有旧组的数据传播到新组，然后删除异步复制连接并升级任何缺失的成员。

滚动复制升级

在这种方法中，您创建一个由运行较新版本的成员组成的第二组，并将旧组缺失的数据复制到较新组。这假定您有足够的服务器同时运行两个组。由于在此过程中主服务器的数量不减少，对于运行在多主模式下的组来说，写入可用性不会减少。这使得滚动复制升级非常适合在多主模式下运行的组。这不会影响在单主模式下运行的组。

因为在为新组的成员提供资源时，运行旧版本的组在线，您需要确保运行较新版本的组赶上在为成员提供资源时执行的任何事务。因此，新组中的一个服务器被配置为旧组的主服务器的副本。这确保新组赶上旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此它在相同的异步源-副本复制的假设和要求下受支持，请参阅第十九章，复制。对于在单主模式下运行的组，异步复制连接到旧组必须将数据发送到新组的主服务器，对于多主组，异步复制通道可以连接到任何主服务器。

过程是：

部署适当数量的成员，以便运行较新版本的组可以处理成员的故障
对组中的一个成员进行现有数据的备份
使用来自旧成员的备份为新组的成员提供资源，请参阅第 20.8.3.4 节，“使用mysqlbackup进行组复制升级”中的一种方法。注意您必须将备份还原到与备份所在的 MySQL 版本相同的版本，然后执行就地升级。有关说明，请参阅第三章，升级 MySQL。
创建一个包含升级成员的新组，请参阅第二十章，组复制。在这种情况下，您需要在每个成员上配置一个新的组名（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加其余的升级成员。
在旧组和新组之间建立一个异步复制通道，请参阅第 19.1.3.4 节，“使用 GTIDs 设置复制”。将较旧的主服务器配置为异步复制源服务器，将新组成员配置为基于 GTID 的副本。

一旦新组中缺失的持续数据量足够小，可以快速传输，您必须将写操作重定向到新组。等到所有旧组的数据传播到新组，然后断开异步复制连接。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade-with-mysqlbackup.html

20.8.3.4 使用mysqlbackup进行组复制升级

作为一种供应方法的一部分，您可以使用 MySQL 企业备份将数据从一个组成员复制并恢复到新成员。但是，您不能直接使用此技术将从运行较旧版本 MySQL 的成员中获取的备份直接恢复到运行较新版本 MySQL 的成员。解决方案是将备份恢复到运行与备份来源成员相同版本 MySQL 的新服务器实例，然后升级该实例。此过程包括：

从较旧组的成员使用mysqlbackup进行备份。参见第 20.5.6 节，“使用 MySQL 企业备份与组复制”。
部署一个新的服务器实例，该实例必须运行与获取备份的较旧成员相同版本的 MySQL。
使用mysqlbackup将备份从较旧成员恢复到新实例。
在新实例上升级 MySQL，请参见第三章，升级 MySQL。

重复此过程以创建适当数量的新实例，例如以处理故障转移。然后根据第 20.8.3.3 节，“组复制在线升级方法”将实例加入到组中。

20.9 组复制变量

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-options.html

20.9.1 组复制系统变量

20.9.2 组复制状态变量

接下来的两个部分包含了关于 MySQL 服务器系统和服务器状态变量的信息，这些变量是特定于组复制插件的。

表 20.4 组复制变量和选项摘要

名称	命令行	选项文件	系统变量	状态变量	变量范围	动态
group_replication_advertise_recovery_endpoints	是	是	是		全局	是
group_replication_allow_local_lower_version_join	是	是	是		全局	是
group_replication_auto_increment_increment	是	是	是		全局	是
group_replication_autorejoin_tries	是	是	是		全局	是
group_replication_bootstrap_group	是	是	是		全局	是
group_replication_clone_threshold	是	是	是		全局	是
group_replication_communication_debug_options	是	是	是		全局	是
group_replication_communication_max_message_size	是	是	是		全局	是
group_replication_communication_stack			是		全局	否
group_replication_components_stop_timeout	是	是	是		全局	是
group_replication_compression_threshold	是	是	是		全局	是
group_replication_consistency	是	是	是		两者	是
group_replication_enforce_update_everywhere_checks	是	是	是		全局	是
group_replication_exit_state_action	是	是	是		全局	是
group_replication_flow_control_applier_threshold	是	是	是		全局	是
group_replication_flow_control_certifier_threshold	是	是	是		全局	是
group_replication_flow_control_hold_percent	是	是	是		全局	是
group_replication_flow_control_max_quota	是	是	是		全局	是
group_replication_flow_control_member_quota_percent	是	是	是		全局	是
group_replication_flow_control_min_quota	是	是	是		全局	是
group_replication_flow_control_min_recovery_quota	是	是	是		全局	是
group_replication_flow_control_mode	是	是	是		全局	是
group_replication_flow_control_period	是	是	是		全局	是
group_replication_flow_control_release_percent	是	是	是		全局	是
group_replication_force_members	是	是	是		全局	是
group_replication_group_name	是	是	是		全局	是
group_replication_group_seeds	是	是	是		全局	是
group_replication_gtid_assignment_block_size	是	是	是		全局	是
group_replication_ip_allowlist	是	是	是		全局	是
group_replication_ip_whitelist	是	是	是		全局	是
group_replication_local_address	是	是	是		全局	是
group_replication_member_expel_timeout	是	是	是		全局	是
group_replication_member_weight	是	是	是		全局	是
group_replication_message_cache_size	是	是	是		全局	是
group_replication_paxos_single_leader	是	是	是		全局	是
group_replication_poll_spin_loops	是	是	是		全局	是
group_replication_primary_member				是	全局	否
group_replication_recovery_complete_at	是	是	是		全局	是
group_replication_recovery_get_public_key	是	是	是		全局	是
group_replication_recovery_public_key_path	是	是	是		全局	是
group_replication_recovery_reconnect_interval	是	是	是		��局	是
group_replication_recovery_retry_count	是	是	是		全局	是
group_replication_recovery_ssl_ca	是	是	是		全局	是
group_replication_recovery_ssl_capath	是	是	是		全局	是
group_replication_recovery_ssl_cert	是	是	是		全局	是
group_replication_recovery_ssl_cipher	是	是	是		全局	是
group_replication_recovery_ssl_crl	是	是	是		全局	是
group_replication_recovery_ssl_crlpath	是	是	是		全局	是
group_replication_recovery_ssl_key	是	是	是		全局	是
group_replication_recovery_ssl_verify_server_cert	是	是	是		全局	是
group_replication_recovery_tls_ciphersuites	是	是	是		全局	是
group_replication_recovery_tls_version	是	是	是		全局	是
group_replication_recovery_use_ssl	是	是	是		全局	是
group_replication_single_primary_mode	是	是	是		全局	是
group_replication_ssl_mode	是	是	是		全局	是
group_replication_start_on_boot	是	是	是		全局	是
group_replication_transaction_size_limit	是	是	是		全局	是
group_replication_unreachable_majority_timeout	是	是	是		全局	是
group_replication_view_change_uuid	是	是	是		全局	是
名称	命令行	选项文件	系统变量	状态变量	变量范围	动态

20.9.1 Group Replication 系统变量

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html

本节列出了特定于 Group Replication 插件的系统变量。

每个 Group Replication 系统变量的名称都以group_replication_为前缀。

注意

InnoDB Cluster 使用 Group Replication，但 Group Replication 系统变量的默认值可能与本节中记录的默认值不同。例如，在 InnoDB Cluster 中，group_replication_communication_stack的默认值是MYSQL，而不是默认 Group Replication 实现的XCOM。

更多信息，请参阅 MySQL InnoDB Cluster。

一些 Group Replication 组成员的系统变量，包括一些 Group Replication 特定的系统变量和一些通用的系统变量，都是组范围的配置设置。这些系统变量在所有组成员上必须具有相同的值，并且需要对组进行完全重启（由具有group_replication_bootstrap_group=ON的服务器引导）才能使值更改生效。有关在所有成员已停止的组中重新启动的说明，请参阅 Section 20.5.2, “Restarting a Group”。

如果运行中的组对于组范围的配置设置有一个值设置，而加入的成员对于该系统变量有不同的值设置，则加入的成员在值匹配之前无法加入该组。如果组对于这些系统变量中的一个设置了一个值，而加入的成员不支持该系统变量，则无法加入该组。

以下系统变量是组范围的配置设置：

group_replication_single_primary_mode
group_replication_enforce_update_everywhere_checks
group_replication_gtid_assignment_block_size
group_replication_view_change_uuid
group_replication_paxos_single_leader
group_replication_communication_stack（这是一个特殊情况，不受 Group Replication 自身检查的限制；有关详细信息，请参阅系统变量描述）
default_table_encryption
lower_case_table_names
transaction_write_set_extraction（从 MySQL 8.0.26 开始已弃用）

在 Group Replication 运行时无法通过通常的方法更改组范围的配置设置。然而，从 MySQL 8.0.16 开始，您可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode()函数在组仍在运行时更改group_replication_single_primary_mode和group_replication_enforce_update_everywhere_checks的值。更多信息，请参阅 Section 20.5.1.2, “Changing the Group Mode”。

大多数 Group Replication 的系统变量在不同的组成员上可以有不同的值。对于以下系统变量，建议在组的所有成员上设置相同的值，以避免事务不必要的回滚、消息传递失败或消息恢复失败：

group_replication_auto_increment_increment
group_replication_communication_max_message_size
group_replication_compression_threshold
group_replication_message_cache_size
group_replication_transaction_size_limit

大多数 Group Replication 的系统变量被描述为动态的，它们的值可以在服务器运行时更改。然而，在大多数情况下，更改只有在您使用STOP GROUP_REPLICATION语句停止并重新启动组复制后才会生效，随后是一个START GROUP_REPLICATION语句。以下系统变量的更改在不停止和重新启动 Group Replication 的情况下生效：

group_replication_advertise_recovery_endpoints
group_replication_autorejoin_tries
group_replication_consistency
group_replication_exit_state_action
group_replication_flow_control_applier_threshold
group_replication_flow_control_certifier_threshold
group_replication_flow_control_hold_percent
group_replication_flow_control_max_quota
group_replication_flow_control_member_quota_percent
group_replication_flow_control_min_quota
group_replication_flow_control_min_recovery_quota
group_replication_flow_control_mode
group_replication_flow_control_period
group_replication_flow_control_release_percent
group_replication_force_members
group_replication_ip_allowlist
group_replication_ip_whitelist
group_replication_member_expel_timeout
group_replication_member_weight
group_replication_transaction_size_limit
group_replication_unreachable_majority_timeout

当您更改任何 Group Replication 系统变量的值时，请记住，如果在每个成员同时通过 STOP GROUP_REPLICATION 语句或系统关闭停止 Group Replication 的某一点，那么必须像第一次启动一样通过引导重新启动组。有关安全执行此操作的说明，请参见 Section 20.5.2, “重新启动组”。对于整个组的配置设置，这是必需的，但如果您正在更改其他设置，请尽量确保至少有一个成员始终在运行。

重要

如果将一些 Group Replication 的系统变量作为命令行参数传递给服务器，则在服务器启动期间，一些 Group Replication 的系统变量在启动时并未完全验证。这些系统变量包括 group_replication_group_name、group_replication_single_primary_mode、group_replication_force_members、SSL 变量和流量控制系统变量。它们只在服务器启动后完全验证。
指定组成员的 IP 地址或主机名的 Group Replication 系统变量在发出 START GROUP_REPLICATION 语句之前不会被验证。直到那时，Group Replication 的组通信系统 (GCS) 才可用于验证这些值。

专用于 Group Replication 插件的系统变量如下：

group_replication_advertise_recovery_endpoints

命令行格式	--group-replication-advertise-recovery-endpoints=value
引入版本	8.0.21
系统变量	group_replication_advertise_recovery_endpoints
作用范围	全局
动态	是
SET_VAR 提示适用	否
类型	字符串
默认值	DEFAULT

此系统变量的值可以在 Group Replication 运行时更改。更改立即在成员上生效。但是，已经接收到系统变量先前值的加入成员将继续使用该值。只有在值更改后加入的成员才会接收新值。

group_replication_advertise_recovery_endpoints指定加入成员如何为分布式恢复的状态传输与现有成员建立连接。该连接用于远程克隆操作和从捐赠者的二进制日志进行状态传输。

值为DEFAULT，即默认设置，表示加入成员使用现有成员的标准 SQL 客户端连接，如 MySQL Server 的hostname和port系统变量所指定。如果report_port系统变量指定了替代端口号，则使用该端口号。性能模式表replication_group_members在MEMBER_HOST和MEMBER_PORT字段中显示此连接的地址和端口号。这是截至 MySQL 8.0.20 版本的组成员的行为。

您可以指定一个或多个分布式恢复端点，而不是DEFAULT，现有成员向加入成员广告这些端点供其使用。提供分布式恢复端点可以让管理员单独控制分布式恢复流量，与对组成员的常规 MySQL 客户端连接分开。加入成员按照列表上指定的顺序依次尝试每个端点。

将分布式恢复端点指定为逗号分隔的 IP 地址和端口号列表，例如：

group_replication_advertise_recovery_endpoints= "127.0.0.1:3306,127.0.0.1:4567,[::1]:3306,localhost:3306"

IPv4 和 IPv6 地址以及主机名可以任意组合使用。IPv6 地址必须在方括号中指定。主机名必须解析为本地 IP 地址。不能使用通配符地址格式，也不能指定空列表。请注意，标准 SQL 客户端连接不会自动包含在分布式恢复端点列表中。如果要将其用作端点，必须在列表中明确包含它。

有关如何选择 IP 地址和端口作为分布式恢复端点，以及加入成员如何使用它们的详细信息，请参见 Section 20.5.4.1.1，“选择分布式恢复端点的地址”。要求的摘要如下：

IP 地址不必为 MySQL Server 配置，但必须分配给服务器。
端口必须使用port、report_port或admin_port系统变量为 MySQL Server 配置。
如果使用admin_port，则需要为分布式恢复的复制用户授予适当的权限。
IP 地址不需要添加到由group_replication_ip_allowlist或group_replication_ip_whitelist系统变量指定的组复制允许列表中。
连接的 SSL 要求由group_replication_recovery_ssl_*选项指定。

group_replication_allow_local_lower_version_join

命令行格式	--group-replication-allow-local-lower-version-join[={OFF\|ON}]
系统变量	group_replication_allow_local_lower_version_join
范围	全局
动态	是
SET_VAR提示适用	否
类型	布尔值
默认值	OFF

此系统变量的值可以在运行 Group Replication 时更改，但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。

group_replication_allow_local_lower_version_join允许当前服务器即使运行低于组的 MySQL 服务器版本也加入组。默认设置为OFF，如果运行低于现有组成员的版本，则不允许服务器加入复制组。此标准策略确保组的所有成员能够交换消息并应用事务。请注意，运行 MySQL 8.0.17 或更高版本的成员在检查兼容性时考虑发布的补丁版本。运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7 的成员只考虑主要版本。

仅在以下情况下将group_replication_allow_local_lower_version_join设置为ON：

必须在紧急情况下将服务器添加到组中以提高组的容错能力，且只有旧版本可用。
您希望为一个或多个复制组成员回滚升级，而无需关闭整个组并重新引导。

警告

将此选项设置为ON并不会使新成员与组兼容，并允许其加入组而没有任何防范措施防止现有成员的不兼容行为。为确保新成员的正确操作，请采取以下两项预防措施：

在运行较低版本的服务器加入组之前，请停止该服务器上的所有写操作。
从运行较低版本的服务器加入组的那一点开始，在组中的其他服务器上停止所有写操作。

如果没有这些预防措施，运行较低版本的服务器很可能会遇到困难，并以错误终止。

group_replication_auto_increment_increment

命令行格式	--group-replication-auto-increment-increment=#
系统变量	group_replication_auto_increment_increment
范围	全局
动态	是
SET_VAR提示适用	否
类型	整数
默认值	7
最小值	1
最大值	65535

所有组成员的此系统变量应具有相同的值。在 Group Replication 运行时，您不能更改此系统变量的值。您必须停止 Group Replication，更改系统变量的值，然后在每个组成员上重新启动 Group Replication。在此过程中，系统变量的值允许在组成员之间有所不同，但是一些组成员上的事务可能会被回滚。

group_replication_auto_increment_increment确定在此服务器实例上执行的事务的自增列的连续值之间的间隔。增加一个间隔可以避免在组成员上写入时选择重复的自增值，这会导致事务回滚。默认值 7 代表可用值的数量和复制组的允许最大大小（9 个成员）之间的平衡。如果您的组成员更多或更少，您可以在启动 Group Replication 之前将此系统变量设置为匹配预期的组成员数量。

重要

当group_replication_single_primary_mode为ON时，设置group_replication_auto_increment_increment不起作用。

当在服务器实例上启动组复制时，服务器系统变量auto_increment_increment的值将更改为此值，服务器系统变量auto_increment_offset的值将更改为服务器 ID。当停止组复制时，这些更改将被还原。仅当auto_increment_increment和auto_increment_offset的默认值均为 1 时，才会进行这些更改和还原。如果它们的值已经从默认值修改过，则组复制不会更改它们。在 MySQL 8.0 中，当组复制处于单主模式时，系统变量也不会被修改，只有一个服务器进行写入。

group_replication_autorejoin_tries

命令行格式	--group-replication-autorejoin-tries=#
引入版本	8.0.16
系统变量	group_replication_autorejoin_tries
作用范围	全局
动态	是
SET_VAR 提示适用	否
类型	整数
默认值（≥ 8.0.21）	3
默认值（≤ 8.0.20）	0
最小值	0
最大值	2016

可以在组复制运行时更改此系统变量的值，并且更改会立即生效。当发生需要该行为的问题时，会读取系统变量的当前值。

group_replication_autorejoin_tries指定成员在被驱逐或在达到group_replication_unreachable_majority_timeout设置之前无法联系到大多数组时，尝试自动重新加入组的次数。当成员被驱逐或无法联系到大多数组时，它会尝试重新加入（使用当前插件选项值），然后继续进行进一步的自动重新加入尝试，直到达到指定的尝试次数。在一次不成功的自动重新加入尝试后，成员会在下一次尝试之前等待 5 分钟。如果在没有成员重新加入或停止的情况下耗尽了指定的尝试次数，则成员将执行由group_replication_exit_state_action系统变量指定的操作。

在 MySQL 8.0.20 版本之前，默认设置为 0，表示成员不会尝试自动重新加入。从 MySQL 8.0.21 开始，默认设置为 3，表示成员会自动尝试重新加入群组，每次间隔 5 分钟，最多可以指定 2016 次尝试。

在自动重新加入尝试期间和之间，成员保持在超级只读模式，并且不接受写入，但仍然可以在成员上进行读取，随着时间的推移，过时读取的可能性会增加。如果无法容忍任何时间段内可能出现的过时读取，请将 group_replication_autorejoin_tries 设置为 0。有关自动重新加入功能的更多信息以及在选择此选项的值时的考虑事项，请参见第 20.7.7.3 节，“自动重新加入”。

group_replication_bootstrap_group

命令行格式	--group-replication-bootstrap-group[={OFF\|ON}]
系统变量	group_replication_bootstrap_group
范围	全局
动态	是
SET_VAR 提示适用	否
类型	布尔值
默认值	OFF

group_replication_bootstrap_group 配置此服务器引导群组。此系统变量仅应在一个服务器上设置，并且仅在第一次启动群组或重新启动整个群组时设置。群组引导完成后，将此选项设置为 OFF。应在动态和配置文件中将其设置为 OFF。在运行群组时启动两个服务器或重新启动一个服务器并将此选项设置可能会导致人为的脑裂情况，即引导两个具有相同名称的独立群组。

有关首次引导群组的说明，请参见第 20.2.1.5 节，“引导群组”。有关在已执行和认证事务的情况下安全引导群组的说明，请参见第 20.5.2 节，“重新启动群组”。

group_replication_clone_threshold

命令行格式	--group-replication-clone-threshold=#
引入版本	8.0.17
系统变量	group_replication_clone_threshold
范围	全局
动态	是
SET_VAR 提示适用	否
类型	整数
默认值	9223372036854775807
最小值	1
最大值	9223372036854775807
单位	事务

在 Group Replication 运行时可以更改此系统变量的值，但更改只有在停止并重新启动组成员的 Group Replication 后才会生效。

group_replication_clone_threshold 指定现有成员（捐赠者）和加入成员（接收者）之间的事务间隔，触发在分布式恢复过程中使用远程克隆操作将状态传输给加入成员。如果加入成员和合适的捐赠者之间的事务间隔超过阈值，则 Group Replication 将开始使用远程克隆操作进行分布式恢复。如果事务间隔低于阈值，或者远程克隆操作在技术上不可行，则 Group Replication 直接从捐赠者的二进制日志进行状态传输。

警告

在活动组中不要使用低设置的 group_replication_clone_threshold。如果在远程克隆操作正在进行时组中发生超过阈值的事务数量，加入成员在重新启动后会再次触发远程克隆操作，并可能无限继续。为避免这种情况，请确保将阈值设置为预期在远程克隆操作所需时间内组中可能发生的事务数量更高的数字。

要使用此功能，捐赠者和加入成员必须事先设置为支持克隆。有关说明，请参见 Section 20.5.4.2, “分布式恢复的克隆”。当执行远程克隆操作时，Group Replication 会为您管理它，包括所需的服务器重新启动，前提是设置了 group_replication_start_on_boot=ON。如果没有设置，则必须手动重新启动服务器。远程克隆操作会替换加入成员上的现有数据字典，但如果加入成员有其他组成员上不存在的额外事务，则 Group Replication 会进行检查并不继续进行，因为这些事务将被克隆操作擦除。

默认设置（即 GTID 中事务的最大允许序列号）意味着几乎总是尝试从捐赠者的二进制日志进行状态传输，而不是克隆。但是，请注意，无论您的阈值如何，Group Replication 始终尝试执行克隆操作，如果从捐赠者的二进制日志中无法进行状态传输，例如因为加入成员所需的事务在任何现有组成员的二进制日志中都不可用。如果您不希望在复制组中完全使用克隆，请不要在成员上安装克隆插件。

group_replication_communication_debug_options

命令行格式	--group-replication-communication-debug-options=value
系统变量	group_replication_communication_debug_options
范围	全局
动态	是
SET_VAR提示适用	否
类型	字符串
默认值	GCS_DEBUG_NONE
有效数值	GCS_DEBUG_NONE``GCS_DEBUG_BASIC``GCS_DEBUG_TRACE``XCOM_DEBUG_BASIC``XCOM_DEBUG_TRACE``GCS_DEBUG_ALL

在 Group Replication 运行时可以更改此系统变量的值，并立即生效。

group_replication_communication_debug_options 配置不同 Group Replication 组件（如 Group Communication System（GCS）和组通信引擎（XCom，一种 Paxos 变体））提供的调试消息级别。调试信息存储在数据目录中的GCS_DEBUG_TRACE文件中。

可以组合作为字符串指定的可用选项集。以下选项可用：

GCS_DEBUG_NONE 禁用 GCS 和 XCom 的所有调试级别。
GCS_DEBUG_BASIC 在 GCS 中启用基本调试信息。
GCS_DEBUG_TRACE 在 GCS 中启用跟踪信息。
XCOM_DEBUG_BASIC 在 XCom 中启用基本调试信息。
XCOM_DEBUG_TRACE 在 XCom 中启用跟��信息。
GCS_DEBUG_ALL 在 GCS 和 XCom 中启用所有调试级别。

将调试级别设置为GCS_DEBUG_NONE仅在没有任何其他选项的情况下提供时才生效。将调试级别设置为GCS_DEBUG_ALL会覆盖所有其他选项。

group_replication_communication_max_message_size

命令行格式	--group-replication-communication-max-message-size=#
引入	8.0.16
系统变量	group_replication_communication_max_message_size
范围	全局
动态	是
SET_VAR提示适用	否
类型	整数
默认值	10485760
最小值	0
最大值	1073741824
单位	字节

所有组成员应该具有相同的系统变量值。在组复制运行时，无法更改此系统变量的值。您必须停止组复制，更改系统变量的值，然后在每个组成员上重新启动组复制。在此过程中，系统变量的值允许在组成员之间有所不同，但某些组成员上的事务可能会被回滚。

group_replication_communication_max_message_size指定了组复制通信的最大消息大小。超过此大小的消息会自动分割成片段单独发送，并由接收方重新组装。更多信息，请参见第 20.7.5 节，“消息分段”。

默认情况下，最大消息大小为 10485760 字节（10 MiB），这意味着在 MySQL 8.0.16 版本中默认使用分段。最大允许值与replica_max_allowed_packet和slave_max_allowed_packet系统变量的最大值相同，即 1073741824 字节（1 GB）。group_replication_communication_max_message_size的设置必须小于replica_max_allowed_packet或slave_max_allowed_packet的设置，因为应用程序线程无法处理大于最大允许数据包大小的消息片段。要关闭分段，请为group_replication_communication_max_message_size指定零值。

为了使复制组的成员使用分段，组的通信协议版本必须是 MySQL 8.0.16 或更高。使用group_replication_get_communication_protocol()函数查看组的通信协议版本。如果使用较低版本，则组成员不会分段消息。如果所有组成员支持，可以使用group_replication_set_communication_protocol()函数将组的通信协议设置为更高版本。更多信息，请参阅 Section 20.5.1.4, “设置组的通信协议版本”。

group_replication_communication_stack

引入版本	8.0.27
系统变量	group_replication_communication_stack
作用范围	全局
动态	否
SET_VAR提示适用	否
类型	字符串
默认值	XCOM
有效值	XCOM``MYSQL

注意

这个系统变量实际上是一个整个组的配置设置，更改生效需要对复制组进行完全重启。

group_replication_communication_stack指定了是使用 XCom 通信栈还是 MySQL 通信栈来建立组成员之间的组通信连接。XCom 通信栈是 Group Replication 自己的实现，在 MySQL 8.0.27 之前的所有版本中始终使用，并且不支持认证或网络命名空间。MySQL 通信栈是 MySQL 服务器的本机实现，支持认证和网络命名空间，并在发布后立即访问新的安全功能。组的所有成员必须使用相同的通信栈。

当你使用 MySQL 的通信栈代替 XCom 时，MySQL 服务器使用自己的认证和加密协议在组成员之间建立每个连接。

注意

如果你正在使用 InnoDB Cluster，group_replication_communication_stack的默认值是MYSQL。

更多信息，请参阅 MySQL InnoDB Cluster。

在设置组使用 MySQL 通信堆栈时需要进行额外配置；请参阅第 20.6.1 节，“连接安全管理的通信堆栈”。

group_replication_communication_stack 实际上是一个组范围的配置设置，所有组成员必须具有相同的设置。但是，Group Replication 对于组范围配置设置并不执行检查。具有与其余组不同值的成员无法与其他成员通信，因为通信协议不兼容，因此无法交换有关其配置设置的信息。

这意味着虽然在 Group Replication 运行时可以更改系统变量的值，并在重新启动组成员的情况下生效，但成员仍然无法重新加入组，直到在所有成员上更改了设置。因此，您必须在所有成员上停止 Group Replication 并更改系统变量的值，然后才能重新启动组。由于所有成员都已停止，因此需要对组进行完全重启（由具有 group_replication_bootstrap_group=ON 的服务器引导）以使值更改生效。有关从一种通信堆栈迁移到另一种的说明，请参阅第 20.6.1 节，“连接安全管理的通信堆栈”。

group_replication_components_stop_timeout

命令行格式	--group-replication-components-stop-timeout=#
系统变量	group_replication_components_stop_timeout
范围	全局
动态	是
SET_VAR 提示适用	否
类型	整数
默认值（≥ 8.0.27）	300
默认值（≤ 8.0.26）	31536000
最小值	2
最大值	31536000
单位	秒

此系统变量的值可以在 Group Replication 运行时更改，但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。

group_replication_components_stop_timeout 指定 Group Replication 在关闭时等待其各个模块完成正在进行的进程的时间，单位为秒。组件超时在发出 STOP GROUP_REPLICATION 语句后应用，该语句在服务器重新启动或自动重新加入时会自动执行。

超时时间用于解决 Group Replication 组件无法正常停止的情况，这可能发生在成员处于错误状态时被驱逐出组，或者在诸如 MySQL Enterprise Backup 正在持有成员上的表的全局锁时。在这种情况下，成员无法停止应用程序线程或完成分布式恢复过程以重新加入。STOP GROUP_REPLICATION 不会完成，直到情况得到解决（例如，通过释放锁），或者组件超时到期并且模块无论其状态如何都会被关闭。

在 MySQL 8.0.27 之前，默认组件超时时间为 31536000 秒，即 365 天。在这种情况下，组件超时对于描述的情况并不起作用，因此建议设置一个较低的值。从 MySQL 8.0.27 开始，默认值为 300 秒，因此如果在此时间之前未解决问题，Group Replication 组件将在 5 分钟后停止，允许成员重新启动并重新加入。

group_replication_compression_threshold

命令行格式	--group-replication-compression-threshold=#
系统变量	group_replication_compression_threshold
范围	全局
动态	是
SET_VAR 提示适用	否
类型	整数
默认值	1000000
最小值	0
最大值	4294967295
单位	字节

在组成员之间发送的消息超过此阈值字节时应用压缩。如果此系统变量设置为零，则禁用压缩。group_replication_compression_threshold 的值应在所有组成员上保持一致。

Group Replication 使用 LZ4 压缩算法来压缩组内发送的消息。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。此限制低于 group_replication_compression_threshold 系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。使用 LZ4 压缩算法时，请不要为 group_replication_compression_threshold 设置大于 2113929216 字节的值，因为启用消息压缩时，超过此大小的事务无法提交。

更多信息，请参见第 20.7.4 节，“消息压缩”。

group_replication_consistency

命令行格式	--group-replication-consistency=value
引入版本	8.0.14
系统变量	group_replication_consistency
范围	全局，会话
动态	是
SET_VAR 提示适用	否
类型	枚举
默认值	EVENTUAL
有效值	EVENTUAL``BEFORE_ON_PRIMARY_FAILOVER``BEFORE``AFTER``BEFORE_AND_AFTER

在运行 Group Replication 时可以更改此系统变量的值。group_replication_consistency 是一个服务器系统变量，而不是 Group Replication 插件特定的变量，因此不需要重新启动 Group Replication 才能使更改生效。更改系统变量的会话值会立即生效，更改全局值会影响在更改后启动的新会话。需要 GROUP_REPLICATION_ADMIN 权限才能更改此系统变量的全局设置。

group_replication_consistency 控制组提供的事务一致性保证。您可以全局配置一致性，也可以针对每个事务进行配置。group_replication_consistency 还配置了单主组中新选举的主节点使用的围栏机制。必须考虑该变量对只读（RO）和读写（RW）事务的影响。以下列表显示了该变量的可能值，按照事务一致性保证递增的顺序排列：

EVENTUAL 在执行之前，RO 和 RW 事务都不会等待前置事务被应用。这是在添加此变量之前 Group Replication 的行为。一个 RW 事务不会等待其他成员应用事务。这意味着一个事务在其他成员之前可能在一个成员上被外部化。这也意味着在主要故障转移发生时，新的主要成员可以在之前的主要事务全部应用之前接受新的 RO 和 RW 事务。RO 事务可能导致过时的值，RW 事务可能由于冲突而导致回滚。
BEFORE_ON_PRIMARY_FAILOVER 具有新选举的主要成员正在应用来自旧主要成员的积压时，新的 RO 或 RW 事务将被保留（不被应用），直到任何积压都被应用。这确保了主要故障转移发生时，无论是故意还是非故意，客户端始终看到主要成员上的最新值。这保证了一致性，但意味着客户端必须能够处理应用积压时的延迟。通常这种延迟应该是最小的，但取决于积压的大小。
BEFORE 一个 RW 事务在被应用之前等待所有前置事务完成。一个 RO 事务在执行之前等待所有前置事务完成。这确保了该事务通过仅影响事务的延迟来读取最新值。这减少了每个 RW 事务上同步的开销，通过确保同步仅在 RO 事务上使用。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
AFTER 一个 RW 事务等待直到其更改已应用到所有其他成员。这个值对 RO 事务没有影响。这种模式确保了当事务在本地成员上提交时，任何后续事务都会读取任何组成员上写入的值或更近期的值。在主要用于 RO 操作的组中使用此模式，以确保一旦提交，应用的 RW 事务就会在所有地方应用。您的应用程序可以使用此模式确保后续读取获取包含最新写入的最新数据。这减少了每个 RO 事务上同步的开销，通过确保同步仅在 RW 事务上使用。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
BEFORE_AND_AFTER 一个 RW 事务等待 1) 所有前置事务完成后才被应用，2) 直到其更改在其他成员上被应用。一个 RO 事务在执行之前等待所有前置事务完成。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。

有关更多信息，请参见 Section 20.5.3, “事务一致性保证”。

group_replication_enforce_update_everywhere_checks

命令行格式	--group-replication-enforce-update-everywhere-checks[={OFF\|ON}]
系统变量	group_replication_enforce_update_everywhere_checks
范围	全局
动态	是
SET_VAR 提示适用	否
类型	布尔值
默认值	OFF

注意

这个系统变量是一个群组范围的配置设置，需要对复制组进行完全重启才能使更改生效。

group_replication_enforce_update_everywhere_checks 启用或禁用多主更新到处的严格一致性检查。默认情况下，检查是禁用的。在单主模式下，所有群组成员必须禁用此选项。在多主模式下，当启用此选项时，语句将按以下方式进行检查，以确保它们与多主模式兼容：

如果事务在 SERIALIZABLE 隔离级别下执行，则在与群组同步时其提交将失败。
如果事务针对具有级联约束的外键的表执行，则在与群组同步时，事务将无法提交。

这个系统变量是一个群组范围的配置设置。在所有群组成员上必须具有相同的值，在 Group Replication 运行时不能更改，并且需要通过一个具有 group_replication_bootstrap_group=ON 的服务器进行完全重启群组（引导）以使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明，请参见 Section 20.5.2, “重新启动群组”。

如果群组为此系统变量设置了一个值，并且加入的成员为该系统变量设置了不同的值，则加入的成员在将值更改为匹配之前无法加入群组。如果群组成员为此系统变量设置了一个值，而加入的成员不支持该系统变量，则无法加入群组。

从 MySQL 8.0.16 版本开始，您可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode()函数在群组仍在运行时更改此系统变量的值。有关更多信息，请参见第 20.5.1.2 节，“更改群组模式”。

group_replication_exit_state_action

命令行格式	--group-replication-exit-state-action=value
引入版本	8.0.12
系统变量	group_replication_exit_state_action
作用范围	全局
动态	是
SET_VAR 提示适用	否
类型	枚举
默认值（≥ 8.0.16）	READ_ONLY
默认值（≥ 8.0.12, ≤ 8.0.15）	ABORT_SERVER
有效取值（≥ 8.0.18）	ABORT_SERVER``OFFLINE_MODE``READ_ONLY
有效取值（≥ 8.0.12, ≤ 8.0.17）	ABORT_SERVER``READ_ONLY

当 Group Replication 在运行时，可以更改此系统变量的值，并且更改会立即生效。当发生需要该行为的问题时，会读取系统变量的当前值。

group_replication_exit_state_action 配置了当此服务器实例意外离开群组时 Group Replication 的行为，例如在遇到应用程序错误后，或在丢失多数情况下，或当群组的另一个成员因超时而将其驱逐时。在丢失多数情况下，成员离开群组的超时期由group_replication_unreachable_majority_timeout系统变量设置，而对于怀疑的超时期由group_replication_member_expel_timeout系统变量设置。请注意，被驱逐的群组成员在重新连接到群组之前不知道自己被驱逐，因此只有在成员成功重新连接或成员对自己提出怀疑并驱逐自己时才会执行指定的操作。

当由于超时的怀疑或多数丢失而将组成员驱逐时，如果成员将group_replication_autorejoin_tries系统变量设置为指定自动重新加入尝试次数，则首先在超级只读模式下进行指定次数的尝试，然后按照group_replication_exit_state_action指定的操作进行。在出现应用程序错误时不会进行自动重新加入尝试，因为这些错误无法恢复。

当group_replication_exit_state_action设置为READ_ONLY时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将将 MySQL 切换到超级只读模式（通过将系统变量super_read_only设置为ON）。READ_ONLY退出操作是在引入系统变量之前的 MySQL 8.0 版本中的行为，并且从 MySQL 8.0.16 开始再次成为默认设置。

当group_replication_exit_state_action设置为OFFLINE_MODE时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将将 MySQL 切换到离线模式（通过将系统变量offline_mode设置为ON）。在此模式下，连接的客户端用户在下一次请求时将被断开连接，不再接受连接，但具有CONNECTION_ADMIN权限（或已弃用的SUPER权限）的客户端用户除外。Group Replication 还将系统变量super_read_only设置为ON，因此即使使用CONNECTION_ADMIN或SUPER权限连接，客户端也无法进行任何更新。OFFLINE_MODE退出操作从 MySQL 8.0.18 开始提供。

当group_replication_exit_state_action设置为ABORT_SERVER时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将关闭 MySQL。此设置从 MySQL 8.0.12（添加系统变量时）到 MySQL 8.0.15（含）期间为默认设置。

重要提示

如果成员成功加入组之前发生故障，则指定的退出操作不会执行。如果在本地配置检查期间发生故障，或者加入成员的配置与组的配置不匹配，则会出现这种情况。在这些情况下，super_read_only系统变量保持其原始值，继续接受连接，并且服务器不会关闭 MySQL。因此，为了确保在 Group Replication 未启动时服务器无法接受更新，我们建议在服务器启动时在配置文件中设置super_read_only=ON，Group Replication 在成功启动后会将其更改为OFF。当服务器配置为在服务器启动时启动 Group Replication（group_replication_start_on_boot=ON命令手动启动 Group Replication 时也很有用。

有关使用此选项的更多信息以及采取退出操作的全部情况，请参见 Section 20.7.7.4, “退出操作”。

group_replication_flow_control_applier_threshold

命令行格式	--group-replication-flow-control-applier-threshold=#
系统变量	group_replication_flow_control_applier_threshold
范围	全局
动态	是
SET_VAR提示适用	否
类型	整数
默认值	25000
最小值	0
最大值	2147483647
单位	事务