原文:
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 地址白名单来建立安全边界。
译文:
dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html
从 MySQL 8.0.27 开始,Group Replication 可以通过以下方法之一保护成员之间的组通信连接:
通过设置系统变量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
系统变量,其中包含所有组成员的本地地址。
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
。
group_replication_recovery_use_ssl
和其他group_replication_recovery_*
系统变量在第 20.6.3.2 节,“用于分布式恢复的安全套接字层(SSL)连接”中有解释。
group_replication_ip_allowlist
和group_replication_ip_whitelist
系统变量将被忽略,无需配置。
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 通信堆栈的要求。
注意
group_replication_local_address
系统变量)不能使用这些。通过发出CHANGE REPLICATION SOURCE TO
语句取消设置。
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 的情况下默认设置)的服务器将无法加入该组。重要的是要注意,由于组复制甚至无法看到加入尝试,因此它不会检查并用错误消息拒绝加入成员。相反,当先前的通信堆栈放弃尝试联系新的通信堆栈时,尝试加入会悄无声息地失败。
原文:
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 密码套件。 |
重要提示
group_replication_recovery_tls_version
系统变量)。
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 节,“保护分布式恢复连接”以了解如何配置安全设置。
原文:
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
从二进制日志进行状态传输需要具有正确权限的复制用户,以便 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 节,“安全提供复制用户凭据”中的说明进行操作。
默认情况下,在 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
,例如通过中间人攻击。
需要 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 节,“连接安全管理的通信堆栈”。
要为复制用户提供用户凭据,您可以将它们永久设置为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
重要
当使用 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 版本开始提供。
原文:
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
指定的地址。加入成员必须通过白名单允许其对组的初始连接,以便检索用于分布式恢复的地址或地址。
在白名单中,您可以指定以下任意组合:
198.51.100.44
)
192.0.2.21/24
)
2001:db8:85a3:8d3:1319:8a2e:370:7348
)
2001:db8:85a3:8d3::/64
)
example.org
)
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 文件在本地实现名称解析,以避免使用外部组件。
原文:
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”。
原文:
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;
原文:
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
监控机制通过每个成员部署一组探针来收集有关其工作队列和吞吐量的信息来运作。然后定期将该信息传播给组,以与其他成员共享数据。
这些探针分散在插件堆栈中,允许建立诸如以下指标:
一旦成员收到来自另一成员的带有统计信息的消息,它会计算关于上一个监控周期内认证、应用和本地执行的事务数量的其他指标。
监控数据定期与组内其他成员共享。监控周期必须足够长,以便其他成员决定当前的写入请求,但又足够短,以便对组带宽影响最小。信息每秒共享一次,这个周期足以解决这两个问题。
原文:
dev.mysql.com/doc/refman/8.0/en/group-replication-throttling.html
基于在组中所有服务器收集的指标,限流机制会启动并决定是否限制成员能够执行/提交新事务的速率。
因此,从所有成员获取的指标是计算每个成员容量的基础:如果成员有一个大队列(用于认证或应用程序线程),那么执行新事务的能力应该接近上个周期认证或应用的事务。
组中所有成员的最低容量确定了组的实际容量,而本地事务的数量确定了有多少成员正在向其写入,因此,可用容量应该与多少成员共享。
这意味着每个成员都有一个根据可用容量确定的已建立的写入配额,换句话说,它可以安全地为下一个周期发出的事务数量。如果认证者或二进制日志应用程序的队列大小超过用户定义的阈值,写入配额将由限流机制执行。
配额将减少上个周期延迟的事务数量,然后再减少 10%,以允许触发问题的队列减小其大小。为了避免一旦队列大小超过阈值就出现大幅增加的吞吐量,吞吐量在此后每个周期只允许增长相同的 10%。
当前的限流机制不会对低于配额的事务进行惩罚,但会延迟完成那些超出配额的事务,直到监控周期结束。因此,如果写请求的配额非常小,一些事务的延迟可能接近监控周期。
原文:
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_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
状态的组成员返回。
原文:
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 压缩支持
当网络带宽成为瓶颈时,消息压缩可以在组通信级别提供高达 30-40%的吞吐量改进。这在负载下的大型服务器组的情况下尤为重要。组内N个参与者之间的互连是 TCP 点对点的性质,使发送方将相同数量的数据发送N次。此外,二进制日志可能具有较高的压缩比。这使得压缩成为包含大型事务的 Group Replication 工作负载的一个引人注目的特性。
原文:
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
来允许额外的时间(最长一小时),在怀疑已经失败的成员被从组中驱逐之前。
原文:
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
如果一个成员缺席的时间不够长,以至于还没有被从组中驱逐,它可以重新连接并从另一个成员的 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
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 可能暂时超过缓存大小限制。
原文:
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.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
你可以使用group_replication_member_expel_timeout
系统变量,该变量从 MySQL 8.0.13 开始提供,以允许在怀疑创建和怀疑成员被驱逐之间提供额外时间。当一个服务器没有从另一个服务器接收消息时,就会创建怀疑,如第 20.1.4.2 节“故障检测”中所解释的那样。
在 Group Replication 组成员创建对另一个成员(或自身)的怀疑之前,会有一个初始的 5 秒检测期。然后,在另一个成员对其(或自身对自身)的怀疑超时后,该组成员将被驱逐。在此之后可能会有一个短暂的时间段,然后驱逐机制会检测并执行驱逐。group_replication_member_expel_timeout
指定了在创建怀疑和驱逐被怀疑成员之间等待的时间段,称为驱逐超时,期间组成员被列为UNREACHABLE
,但不会从组的成员列表中移除。
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
的值,而不使用默认值:
您可以指定最长达 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
默认情况下,由于网络分区而处于少数派的成员不会自动离开群组。您可以使用系统变量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
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
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_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 关闭 |
原文:
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 失去法定人数
要理解这种类型的网络分区,以下部分描述了最初有 5 台服务器正确协作的情景,以及一旦只有 2 台服务器在线后组发生的变化。该情景在图中描述。
因此,假设有一个包含这 5 台服务器的组:
199b2df7-4aaf-11e6-bb16-28b2bd168d07
199bb88e-4aaf-11e6-babe-28b2bd168d07
1999b9fb-4aaf-11e6-bb54-28b2bd168d07
19ab72fc-4aaf-11e6-bb51-28b2bd168d07
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 强制执行新的成员配置
假设您回到了只剩下 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
必须为空。
原文:
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
要从命令行启用所有组复制仪器,请在您选择的 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
本节描述了使用工具和事件监视组复制内存使用情况的示例查询。这些查询从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
原文:
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, “群组复制在线升级”,了解升级群组的不同方法以最小化停机时间。
原文:
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 8.0.17 或更高版本的成员在检查兼容性时考虑发布的补丁版本。运行 MySQL 8.0.16 或更低版本,或 MySQL 5.7 的成员只考虑主要版本。例如,如果你有一个所有成员都运行 MySQL 版本 8.0.13 的组:
请注意,运行 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.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
复制组使用的 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”。
原文:
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 服务器版本。
原文:
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
在升级在线组时,您应考虑以下几点:
super_read_only
变量会自动设置为打开,但此更改不会持久保存。
lower_case_table_names
的值。
原文:
dev.mysql.com/doc/refman/8.0/en/group-replication-upgrading-member.html
本节解释了升级组成员所需的步骤。此过程是第 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 升级过程之前,它可能会重新加入组,并可能导致问题。例如,如果升级失败并且服务器再次重启,那么可能会尝试加入组的是一个可能损坏的服务器。
SHUTDOWN
语句。组中的其他成员继续运行。
group_replication_start_on_boot
设置为 0,Group Replication 不会在实例上启动,因此它不会重新加入组。
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
选择以下升级 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, 复制。对于在单主模式下运行的组,向旧组的异步复制连接必须发送数据到新组的主节点,对于多主组,异步复制通道可以连接到任何主节点。
过程如下:
在将应用程序重定向到新组之前,您必须确保新组具有合适数量的成员,例如使组能够处理成员的故障。执行SELECT * FROM performance_schema.replication_group_members
并比较初始组大小和新组大小。等到所有旧组的数据传播到新组,然后删除异步复制连接并升级任何缺失的成员。
在这种方法中,您创建一个由运行较新版本的成员组成的第二组,并将旧组缺失的数据复制到较新组。这假定您有足够的服务器同时运行两个组。由于在此过程中主服务器的数量不减少,对于运行在多主模式下的组来说,写入可用性不会减少。这使得滚动复制升级非常适合在多主模式下运行的组。这不会影响在单主模式下运行的组。
因为在为新组的成员提供资源时,运行旧版本的组在线,您需要确保运行较新版本的组赶上在为成员提供资源时执行的任何事务。因此,新组中的一个服务器被配置为旧组的主服务器的副本。这确保新组赶上旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道,因此它在相同的异步源-副本复制的假设和要求下受支持,请参阅第十九章,复制。对于在单主模式下运行的组,异步复制连接到旧组必须将数据发送到新组的主服务器,对于多主组,异步复制通道可以连接到任何主服务器。
过程是:
一旦新组中缺失的持续数据量足够小,可以快速传输,您必须将写操作重定向到新组。等到所有旧组的数据传播到新组,然后断开异步复制连接。
原文:
dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade-with-mysqlbackup.html
作为一种供应方法的一部分,您可以使用 MySQL 企业备份将数据从一个组成员复制并恢复到新成员。但是,您不能直接使用此技术将从运行较旧版本 MySQL 的成员中获取的备份直接恢复到运行较新版本 MySQL 的成员。解决方案是将备份恢复到运行与备份来源成员相同版本 MySQL 的新服务器实例,然后升级该实例。此过程包括:
重复此过程以创建适当数量的新实例,例如以处理故障转移。然后根据第 20.8.3.3 节,“组复制在线升级方法”将实例加入到组中。
原文:
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 | 是 | 是 | 是 | 全局 | 是 | |
名称 | 命令行 | 选项文件 | 系统变量 | 状态变量 | 变量范围 | 动态 |
原文:
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_name
、group_replication_single_primary_mode
、group_replication_force_members
、SSL 变量和流量控制系统变量。它们只在服务器启动后完全验证。
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,“选择分布式恢复端点的地址”。要求的摘要如下:
port
、report_port
或admin_port
系统变量为 MySQL Server 配置。
admin_port
,则需要为分布式恢复的复制用户授予适当的权限。
group_replication_ip_allowlist
或group_replication_ip_whitelist
系统变量指定的组复制允许列表中。
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 |
单位 | 事务 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_applier_threshold
指定了在应用程序队列中等待的事务数量,触发流量控制。
group_replication_flow_control_certifier_threshold
命令行格式 | --group-replication-flow-control-certifier-threshold=# |
---|---|
系统变量 | group_replication_flow_control_certifier_threshold |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 25000 |
最小值 | 0 |
最大值 | 2147483647 |
单位 | 事务 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_certifier_threshold
指定了在认证者队列中等待的事务数量触发流量控制。
group_replication_flow_control_hold_percent
命令行格式 | --group-replication-flow-control-hold-percent=# |
---|---|
系统变量 | group_replication_flow_control_hold_percent |
作用域 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 10 |
最小值 | 0 |
最大值 | 100 |
单位 | 百分比 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_hold_percent
定义了集群配额剩余未使用的百分比,以允许处于流量控制状态的集群赶上积压工作。 值为 0 意味着没有配额的任何部分用于赶上工作积压。
group_replication_flow_control_max_quota
命令行格式 | --group-replication-flow-control-max-quota=# |
---|---|
系统变量 | group_replication_flow_control_max_quota |
作用域 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 2147483647 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_max_quota
定义了组的最大流量控制配额,或者在启用流量控制时任何时期的最大可用配额。值为 0 意味着没有设置最大配额。此系统变量的值不能小于group_replication_flow_control_min_quota
和group_replication_flow_control_min_recovery_quota
。
group_replication_flow_control_member_quota_percent
命令行格式 | --group-replication-flow-control-member-quota-percent=# |
---|---|
系统变量 | group_replication_flow_control_member_quota_percent |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 100 |
单位 | 百分比 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_member_quota_percent
定义了成员在计算配额时应该假定自己可用的配额百分比。值为 0 意味着配额应该在上一个时期是写入者的成员之间均匀分配。
group_replication_flow_control_min_quota
命令行格式 | --group-replication-flow-control-min-quota=# |
---|---|
系统变量 | group_replication_flow_control_min_quota |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 2147483647 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_min_quota
控制着可以分配给成员的最低流量控制配额,独立于上一个周期执行的计算最小配额。数值为 0 意味着没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota
。
group_replication_flow_control_min_recovery_quota
命令行格式 | --group-replication-flow-control-min-recovery-quota=# |
---|---|
系统变量 | group_replication_flow_control_min_recovery_quota |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 2147483647 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_min_recovery_quota
控制着因为组中另一个正在恢复的成员而可以分配给成员的最低配额,独立于上一个周期执行的计算最小配额。数值为 0 意味着没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota
。
group_replication_flow_control_mode
命令行格式 | --group-replication-flow-control-mode=value |
---|---|
系统变量 | group_replication_flow_control_mode |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 枚举 |
默认值 | QUOTA |
有效值 | DISABLED``QUOTA |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_mode
指定了流量控制的模式。
group_replication_flow_control_period
命令行格式 | --group-replication-flow-control-period=# |
---|---|
系统变量 | group_replication_flow_control_period |
范围 | 全局 |
Dynamic | 是 |
SET_VAR Hint Applies | No |
类型 | 整数 |
默认值 | 1 |
最小值 | 1 |
最大值 | 60 |
单位 | 秒 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_period
定义了在流量控制迭代之间等待多少秒,其中发送流量控制消息并运行流量控制管理任务。
group_replication_flow_control_release_percent
命令行格式 | --group-replication-flow-control-release-percent=# |
---|---|
系统变量 | group_replication_flow_control_release_percent |
范围 | 全局 |
Dynamic | Yes |
SET_VAR Hint Applies | No |
类型 | 整数 |
默认值 | 50 |
最小值 | 0 |
最大值 | 1000 |
单位 | 百分比 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。
group_replication_flow_control_release_percent
定义了当流量控制不再需要限制写入成员时,如何释放组配额,其中百分比是每个流量控制周期的配额增加。 值为 0 意味着一旦流量控制阈值在限制范围内,配额就会在单个流量控制迭代中释放。 该范围允许配额释放高达当前配额的 10 倍,这样可以更好地适应,主要是当流量控制周期较长且配额非常小时。
group_replication_force_members
命令行格式 | --group-replication-force-members=value |
---|---|
系统变量 | group_replication_force_members |
范围 | 全局 |
Dynamic | 是 |
SET_VAR Hint Applies | No |
类型 | 字符串 |
此系统变量用于强制应用新的组成员。在 Group Replication 运行时,可以更改此系统变量的值,并立即生效。您只需要在要保留在组中的一个组成员上设置系统变量的值。有关可能需要强制应用新的组成员的情况以及在使用此系统变量时要遵循的程序的详细信息,请参见第 20.7.8 节,“处理网络分区和失去法定人数”。
group_replication_force_members
指定一组对等地址,以逗号分隔的列表形式,例如host1:port1
,host2:port2
。未包含在列表中的任何现有成员将不会接收到组的新视图,并将被阻止。对于每个要继续作为成员的现有成员,您必须包括 IP 地址或主机名以及端口,就像在group_replication_local_address
系统变量中为每个成员给出的那样。IPv6 地址必须用方括号指定。例如:
"198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061,example.org:33061"
Group Replication 的组通信引擎(XCom)检查提供的 IP 地址是否具有有效格式,并检查您是否包含了当前无法访问的任何组成员。否则,新配置将不被验证,因此您必须小心地只包括在线可访问的组成员。列表中的任何不正确值或无效主机名都可能导致组被阻止,出现无效配置。
在强制应用新的成员配置之前,确保要排除的服务器已关闭是很重要的。如果没有关闭,请在继续之前将它们关闭。仍然在线的组成员可以自动形成新的配置,如果已经发生了这种情况,强制进一步的新配置可能会为组创建人为的脑裂情况。
在使用group_replication_force_members
系统变量成功强制应用新的组成员并解除组阻塞后,请确保清除该系统变量。为了发出START GROUP_REPLICATION
语句,group_replication_force_members
必须为空。
group_replication_group_name
命令行格式 | --group-replication-group-name=value |
---|---|
系统变量 | group_replication_group_name |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值在 Group Replication 运行时无法更改。
group_replication_group_name
指定了此服务器实例所属的组的名称,必须是有效的 UUID。这个 UUID 是 GTID 的一部分,当组成员从客户端接收到事务,以及组成员内部生成的视图更改事件被写入二进制日志时使用。
重要提示
必须使用唯一的 UUID。
group_replication_group_seeds
命令行格式 | --group-replication-group-seeds=value |
---|---|
系统变量 | group_replication_group_seeds |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员的 Group Replication 后才会生效。
group_replication_group_seeds
是一个组成员的列表,加入的成员可以连接到这些组成员以获取所有当前组成员的详细信息。加入的成员使用这些详细信息来选择并连接到一个组成员,以获取与组的同步所需的数据。该列表包含每个包含的种子成员的单个内部网络地址或主机名,如在种子成员的 group_replication_local_address
系统变量中配置的那样(而不是种子成员的 SQL 客户端连接,如 MySQL Server 的 hostname
和 port
系统变量所指定的)。种子成员的地址被指定为逗号分隔的列表,例如 host1:port1
,host2:port2
。IPv6 地址必须用方括号指定。例如:
group_replication_group_seeds= "198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061, example.org:33061"
请注意,您为此变量指定的值在发出 START GROUP_REPLICATION
语句并且 Group Communication System (GCS) 可用之前不会被验证。
通常,此列表包含组的所有成员,但您可以选择一组成员的子集作为种子。列表必须至少包含一个有效成员地址。在启动 Group Replication 时,每个地址都会被验证。如果列表不包含任何有效成员地址,则发出START GROUP_REPLICATION
将失败。
当服务器加入复制组时,它会尝试连接到其group_replication_group_seeds
系统变量中列出的第一个种子成员。如果连接被拒绝,加入成员会尝试按顺序连接列表中的其他种子成员。如果加入成员连接到一个种子成员,但由于某种原因未被添加到复制组(例如,因为种子成员没有在其允许列表中包含加入成员的地址并关闭了连接),则加入成员会继续按顺序尝试剩余的种子成员。
加入成员必须使用与种子成员在group_replication_group_seeds
选项中广告的协议(IPv4 或 IPv6)与种子成员进行通信。对于 Group Replication 的 IP 地址权限,种子成员的允许列表必须包含加入成员的 IP 地址,以便与种子成员提供的协议匹配,或者解析为该协议的地址的主机名。如果加入成员的协议与种子成员广告的协议不匹配,则必须设置并允许此地址或主机名,除了加入成员的group_replication_local_address
。如果加入成员没有适当协议的允许地址,则其连接尝试将被拒绝。有关更多信息,请参见第 20.6.4 节,“Group Replication IP 地址权限”。
group_replication_gtid_assignment_block_size
命令行格式 | --group-replication-gtid-assignment-block-size=# |
---|---|
系统变量 | group_replication_gtid_assignment_block_size |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 整数 |
默认值 | 1000000 |
最小值 | 1 |
最大值(64 位平台) | 9223372036854775807 |
最大值(32 位平台) | 4294967295 |
注意
这个系统变量是一个群组范围的配置设置,需要对复制组进行完全重启才能使更改生效。
group_replication_gtid_assignment_block_size
指定为每个组成员保留的连续 GTID 数。每个成员消耗自己的块,并在需要时保留更多。
这个系统变量是一个群组范围的配置设置。在所有群组成员上必须具有相同的值,不能在 Group Replication 运行时更改,并且需要对群组进行完全重启(由具有 group_replication_bootstrap_group=ON
的服务器引导)才能使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明,请参见 第 20.5.2 节,“重新启动群组”。
如果群组为此系统变量设置了一个值,并且加入成员为该系统变量设置了不同的值,则加入成员无法加入群组,直到将值更改为匹配。如果群组成员为此系统变量设置了一个值,而加入成员不支持该系统变量,则无法加入群组。
group_replication_ip_allowlist
命令行格式 | --group-replication-ip-allowlist=value |
---|---|
引入版本 | 8.0.22 |
系统变量 | group_replication_ip_allowlist |
作用范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 字符串 |
默认值 | AUTOMATIC |
group_replication_ip_allowlist
在 MySQL 8.0.22 中可用,用于替换 group_replication_ip_whitelist
。从 MySQL 8.0.24 开始,可以在 Group Replication 运行时更改此系统变量的值,并且更改立即在成员上生效。
group_replication_ip_allowlist
指定哪些主机被允许连接到组。当 XCom 通信堆栈用于组时(group_replication_communication_stack=XCOM
),白名单用于控制对组的访问。当 MySQL 通信堆栈用于组时(group_replication_communication_stack=MYSQL
),用户认证用于控制对组的访问,白名单不会被使用,如果设置了则会被忽略。
您在group_replication_local_address
中为每个组成员指定的地址必须在复制组中的其他服务器上得到允许。请注意,直到发出START GROUP_REPLICATION
语句并且组通信系统(GCS)可用之前,您为此变量指定的值不会被验证。
默认情况下,此系统变量设置为AUTOMATIC
,允许来自主机上活动的私有子网的连接。组复制的组通信引擎(XCom)会自动扫描主机上的活动接口,并识别具有私有子网地址的接口。这些地址以及 IPv4 和(从 MySQL 8.0.14 开始)IPv6 的localhost
IP 地址用于创建组复制白名单。有关自动允许地址的范围列表,请参见 Section 20.6.4, “Group Replication IP Address Permissions”。
自动私有地址白名单不能用于来自私有网络之外的服务器的连接。对于位于不同机器上的服务器实例之间的组复制连接,您必须提供公共 IP 地址并将其指定为显式白名单。如果为白名单指定了任何条目,则私有地址不会自动添加,因此如果使用其中任何一个,必须明确指定。localhost
IP 地址会自动添加。
作为group_replication_ip_allowlist
选项的值,您可以指定以下任意组合:
198.51.100.44
)
192.0.2.21/24
)
2001:db8:85a3:8d3:1319:8a2e:370:7348
)
2001:db8:85a3:8d3::/64
)
example.org
)
www.example.com/24
)
在 MySQL 8.0.14 之前,主机名只能解析为 IPv4 地址。从 MySQL 8.0.14 开始,主机名可以解析为 IPv4 地址、IPv6 地址或两者都有。如果主机名解析为 IPv4 和 IPv6 地址,始终使用 IPv4 地址进行组复制连接。您可以结合主机名或 IP 地址使用 CIDR 表示法来允许具有特定网络前缀的 IP 地址块,但确保指定子网中的所有 IP 地址都在您的控制之下。
每个允许列表中的条目之间必须用逗号分隔。例如:
"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"
如果组的任何种子成员在加入成员具有 IPv4 group_replication_local_address
时列出了带有 IPv6 地址的group_replication_group_seeds
选项,或反之亦然,则还必须设置和允许加入成员的另一地址,以供种子成员提供的协议使用(或解析为该协议的地址的主机名)。有关更多信息,请参见第 20.6.4 节,“组复制 IP 地址权限”。
可以根据您的安全需求在不同的组成员上配置不同的允许列表,例如,为了保持不同的子网分开。然而,当重新配置组时可能会导致问题。如果没有特定的安全要求要求做出其他安排,请在组的所有成员上使用相同的允许列表。有关更多详细信息,请参见第 20.6.4 节,“组复制 IP 地址权限”。
对于主机名,只有在另一个服务器发出连接请求时才会进行名称解析。无法解析的主机名不会被视为允许列表验证的一部分,并且会向错误日志中写入警告消息。对已解析的主机名执行前向确认反向 DNS(FCrDNS)验证。
警告
主机名在允许列表中比 IP 地址不安全。FCrDNS 验证提供了很好的保护级别,但可能会受到某些类型攻击的影响。仅在绝对必要时在允许列表中指定主机名,并确保所有用于名称解析的组件,如 DNS 服务器,都在您的控制之下。您还可以使用 hosts 文件在本地实现名称解析,以避免使用外部组件。
group_replication_ip_whitelist
命令行格式 | --group-replication-ip-whitelist=value |
---|---|
已弃用 | 8.0.22 |
系统变量 | group_replication_ip_whitelist |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 字符串 |
默认值 | AUTOMATIC |
从 MySQL 8.0.22 开始,group_replication_ip_whitelist
已被弃用,而group_replication_ip_allowlist
可用来替代它。对于这两个系统变量,默认值均为AUTOMATIC
。
在群组复制启动时,如果其中一个系统变量已设置为用户定义的值而另一个没有,则使用更改后的值。如果两个系统变量都已设置为用户定义的值,则使用group_replication_ip_allowlist
的值。
如果在群组复制运行时更改group_replication_ip_whitelist
或group_replication_ip_allowlist
的值,这在 MySQL 8.0.24 中是可能的,那么两个变量都不会优先于另一个。
新的系统变量与旧的系统变量的工作方式相同,只是术语发生了变化。对于group_replication_ip_allowlist
给出的行为描述适用于旧系统变量和新系统变量。
group_replication_local_address
命令行格式 | --group-replication-local-address=value |
---|---|
系统变量 | group_replication_local_address |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在群组复制运行时更改,但更改只在停止并重新启动群组成员的情况下生效。
group_replication_local_address
设置了成员为其他成员提供连接的网络地址,格式为host:port
。这个地址必须被组内所有成员访问,因为它被组通信引擎用于 Group Replication(XCom,一种 Paxos 变体)的 TCP 通信。如果您正在使用 MySQL 通信堆栈在成员之间建立组通信连接(group_replication_communication_stack
= MYSQL),那么该地址必须是 MySQL Server 监听的 IP 地址和端口之一,由服务器的 bind_address
系统变量指定。
警告
不要使用此地址查询或管理成员上的数据库。这不是 SQL 客户端连接的主机和端口。
您在 group_replication_local_address
中指定的地址或主机名被 Group Replication 用作复制组内组成员的唯一标识符。只要主机名或 IP 地址都不同,就可以为复制组的所有成员使用相同的端口,只要端口都不同,就可以为所有成员使用相同的主机名或 IP 地址。group_replication_local_address
的推荐端口是 33061。请注意,直到发出 START GROUP_REPLICATION
语句并且 Group Communication System (GCS) 可用之前,不会验证此变量的值。
由 group_replication_local_address
配置的网络地址必须被所有组成员解析。例如,如果每个服务器实例在不同的机器上具有固定的网络地址,您可以使用机器的 IP 地址,例如 10.0.0.1。如果使用主机名,必须使用完全限定的名称,并确保通过 DNS、正确配置的 /etc/hosts
文件或其他名称解析过程解析。从 MySQL 8.0.14 开始,IPv6 地址(或解析为它们的主机名)也可以使用,以及 IPv4 地址。必须在方括号中指定 IPv6 地址,以区分端口号,例如:
group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"
如果指定为服务器实例的组复制本地地址的主机名同时解析为 IPv4 和 IPv6 地址,则始终使用 IPv4 地址进行组复制连接。有关组复制支持 IPv6 网络以及使用 IPv4 成员和使用 IPv6 成员混合的复制组的更多信息,请参见第 20.5.5 节,“IPv6 和混合 IPv6 和 IPv4 组的支持”。
如果您正在使用 XCom 通信堆栈在成员之间建立组通信连接(group_replication_communication_stack = XCOM
),则在复制组中的其他服务器上必须将您为每个组成员指定的地址添加到group_replication_ip_allowlist
(从 MySQL 8.0.22 开始)或group_replication_ip_whitelist
(对于 MySQL 8.0.21 及更早版本)系统变量的列表中。当 XCom 通信堆栈用于组时,允许列表用于控制对组的访问。当 MySQL 通信堆栈用于组时,用户身份验证用于控制对组的访问,允许列表不起作用,如果设置则会被忽略。请注意,如果组的任何种子成员在此成员具有 IPv4 group_replication_local_address
时列出具有 IPv6 地址,或反之亦然,则还必须设置并允许该成员的所需协议的替代地址(或解析为该协议地址的主机名)。有关更多信息,请参见第 20.6.4 节,“组复制 IP 地址权限”。
group_replication_member_expel_timeout
命令行格式 | --group-replication-member-expel-timeout=# |
---|---|
引入版本 | 8.0.13 |
系统变量 | group_replication_member_expel_timeout |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 (≥ 8.0.21) | 5 |
默认值 (≤ 8.0.20) | 0 |
最小值 | 0 |
最大值 (≥ 8.0.14) | 3600 |
最大值(≤ 8.0.13) | 31536000 |
单位 | 秒 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。系统变量的当前值在 Group Replication 检查超时时读取。并非所有组成员都必须具有相同的设置,但建议如此以避免意外驱逐。
group_replication_member_expel_timeout
指定了在创建怀疑后,Group Replication 组成员在将被怀疑失败的成员从组中驱逐之前等待的时间段(以秒为单位)。在创建怀疑之前的初始 5 秒检测期不计入此时间。在 MySQL 8.0.20 及之前的版本中,group_replication_member_expel_timeout
的值默认为 0,意味着没有等待时间,怀疑的成员在 5 秒检测期结束后立即有可能被驱逐。从 MySQL 8.0.21 开始,默认值为 5,意味着怀疑的成员在 5 秒检测期结束后 5 秒内有可能被驱逐。
在组成员上更改 group_replication_member_expel_timeout
的值会立即对该组成员上现有及未来的怀疑生效。因此,您可以将其用作强制怀疑超时并驱逐怀疑成员以允许更改组配置的方法。有关更多信息,请参见 第 20.7.7.1 节,“驱逐超时”。
增加group_replication_member_expel_timeout
的值可以帮助避免在较慢或不稳定网络上发生不必要的驱逐,或在预期的瞬时网络中断或机器减速情况下。如果可疑成员在疑虑超时之前再次活跃,它会应用所有被其余组成员缓冲的消息,并进入ONLINE
状态,无需操作者干预。您可以指定最多 3600 秒(1 小时)的超时值。重要的是要确保 XCom 的消息缓存足够大,以容纳在指定时间段内预期的消息量,再加上初始的 5 秒检测期,否则成员无法重新连接。您可以使用group_replication_message_cache_size
系统变量调整缓存大小限制。有关更多信息,请参见第 20.7.6 节,“XCom 缓存管理”。
如果超时时间已过,可疑成员在疑虑超时后立即有可能被驱逐。如果成员能够恢复通信并接收到一个将其驱逐的视图,并且成员已将group_replication_autorejoin_tries
系统变量设置为指定自动重新加入尝试次数,则在超级只读模式下,它会继续进行指定数量的重新加入尝试。如果成员没有指定任何自动重新加入尝试,或者已耗尽指定数量的尝试次数,则会执行由系统变量group_replication_exit_state_action
指定的操作。
有关使用group_replication_member_expel_timeout
设置的更多信息,请参见第 20.7.7.1 节,“驱逐超时”。在没有此系统变量的情况下,为避免不必要的驱逐而采取替代缓解策略,请参见第 20.3.2 节,“组复制限制”。
group_replication_member_weight
命令行格式 | --group-replication-member-weight=# |
---|---|
系统变量 | group_replication_member_weight |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 整数 |
默认值 | 50 |
最小值 | 0 |
最大值 | 100 |
单位 | 百分比 |
可以在 Group Replication 运行时更改此系统变量的值,并且更改会立即生效。在发生故障转移情况时,系统变量的当前值会被读取。
group_replication_member_weight
指定了可以分配给成员的百分比权重,以影响在故障转移时成员被选为主要成员的机会,例如当现有主要成员离开单一主要组时。为成员分配数字权重以确保特定成员被选中,例如在主要成员的计划维护期间或在故障转移时确保某些硬件优先考虑。
对于配置为以下成员的组:
成员-1
: group_replication_member_weight=30, server_uuid=aaaa
成员-2
: group_replication_member_weight=40, server_uuid=bbbb
成员-3
: group_replication_member_weight=40, server_uuid=cccc
成员-4
: group_replication_member_weight=40, server_uuid=dddd
在选举新主要成员时,上述成员将按成员-2
、成员-3
、成员-4
和成员-1
的顺序排序。这导致在故障转移时选择成员-2
作为新的主要成员。有关更多信息,请参见 Section 20.1.3.1, “Single-Primary Mode”。
group_replication_message_cache_size
命令行格式 | --group-replication-message-cache-size=# |
---|---|
引入版本 | 8.0.16 |
系统变量 | group_replication_message_cache_size |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 1073741824 (1 GB) |
最小值(64 位平台,≥ 8.0.21) | 134217728 (128 MB) |
最小值(64 位平台,≤ 8.0.20) | 1073741824 (1 GB) |
最小值(32 位平台,≥ 8.0.21) | 134217728 (128 MB) |
最小值(32 位平台,≤ 8.0.20) | 1073741824 (1 GB) |
最大值(64 位平台) | 18446744073709551615 (16 EiB) |
最大值(32 位平台) | 315360004294967295 (4 GB) |
单位 | 字节 |
此系统变量应在所有组成员上具有相同的值。在 Group Replication 运行时可以更改此系统变量的值。更改在您停止并重新启动成员上的 Group Replication 后生效。在此过程中,系统变量的值允许在组成员之间有所不同,但在断开连接的情况下,成员可能无法重新连接。
group_replication_message_cache_size
设置了在 Group Replication(XCom)的组通信引擎中用于消息缓存的最大内存量。XCom 消息缓存保存了作为共识协议的一部分在组成员之间交换的消息(及其元数据)。消息缓存除了其他功能外,还用于在成员在一段时间内无法与其他组成员通信后重新连接到组时恢复丢失的消息。
group_replication_member_expel_timeout
系统变量确定了等待期限(最长一小时),该期限是在初始 5 秒检测期限之外允许成员返回到组中而不被驱逐的。XCom 消息缓存的大小应该根据预期的消息量设置,以便在此时间段内包含所有成员成功返回所需的所有丢失消息。直到 MySQL 8.0.20 版本,仅有 5 秒的检测期限是默认值,但从 MySQL 8.0.21 版本开始,默认值是在 5 秒检测期限之后等待 5 秒,总共为 10 秒的时间段。
确保系统上有足够的内存供您选择的缓存大小限制使用,考虑到 MySQL 服务器的其他缓存和对象池的大小。默认设置为 1073741824 字节(1 GB)。最小设置也是 1 GB,直到 MySQL 8.0.20 版本。从 MySQL 8.0.21 开始,最小设置为 134217728 字节(128 MB),这使得可以在内存可用量受限的主机上部署,并且具有良好的网络连接性,以最小化组成员之间瞬时连接丢失的频率和持续时间。请注意,使用 group_replication_message_cache_size
设置的限制仅适用于缓存中存储的数据,缓存结构需要额外的 50 MB 内存。
缓存大小限制可以在运行时动态增加或减少。如果减少缓存大小限制,XCom 将删除已经决定并传递的最旧条目,直到当前大小低于限制。当从消息缓存中删除可能需要用于恢复的消息,但当前无法访问的成员时,Group Replication 的组通信系统(GCS)会通过警告消息向您发出警告。有关调整消息缓存大小的更多信息,请参见 Section 20.7.6, “XCom Cache Management”。
group_replication_paxos_single_leader
命令行格式 | --group-replication-paxos-single-leader[={OFF|ON}] |
---|---|
引入版本 | 8.0.27 |
系统变量 | group_replication_paxos_single_leader |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 布尔值 |
默认值 | OFF |
注意
此系统变量是一个群组范围的配置设置,需要完全重新启动复制组才能使更改生效。
group_replication_paxos_single_leader
从 MySQL 8.0.27 开始可用。当群组处于单主模式时,它使群组通信引擎能够与单一共识领导者一起运行。使用默认设置OFF
,此行为被禁用,并且在此系统变量可用之前的版本中使用每个群组成员作为领导者的行为。当系统变量设置为ON
时,群组通信引擎可以使用单一领导者来推动共识。在单一共识领导者模式下操作可以提高性能和韧性,特别是当群组的某些次要成员当前无法访问时。有关更多信息,请参见 Section 20.7.3, “Single Consensus Leader”。
为了使群组通信引擎使用单一共识领导者,群组的通信协议版本必须是 MySQL 8.0.27 或更高版本。使用group_replication_get_communication_protocol()
函数查看群组的通信协议版本。如果使用较低版本,则群组无法使用此行为。如果所有群组成员都支持,您可以使用group_replication_set_communication_protocol()
函数将群组的通信协议设置为更高版本。有关更多信息,请参见 Section 20.5.1.4, “Setting a Group’s Communication Protocol Version”。
此系统变量是一个群组范围的配置设置。它必须在所有群组成员上具有相同的值,在 Group Replication 运行时无法更改,并且需要对群组进行完全重新启动(由具有group_replication_bootstrap_group=ON
的服务器引导)才能使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明,请参见 Section 20.5.2, “Restarting a Group”。
如果组为此系统变量设置了一个值,并且加入成员为该系统变量设置了不同的值,则加入成员在值匹配之前无法加入该组。如果组成员为此系统变量设置了一个值,而加入成员不支持该系统变量,则无法加入该组。
在性能模式表replication_group_communication_information
中的字段WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE
显示组是否支持使用单个领导者,即使在查询的成员上当前设置为OFF
的group_replication_paxos_single_leader
。如果组是在设置为ON
的group_replication_paxos_single_leader
并且其通信协议版本为 MySQL 8.0.27 或更高版本的情况下启动的,则该字段设置为 1。
group_replication_poll_spin_loops
命令行格式 | --group-replication-poll-spin-loops=# |
---|---|
系统变量 | group_replication_poll_spin_loops |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值(64 位平台) | 18446744073709551615 |
最大值(32 位平台) | 4294967295 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_poll_spin_loops
指定组通信线程在等待通信引擎互斥锁被释放之前等待更多传入网络消息的次数。
group_replication_recovery_complete_at
命令行格式 | --group-replication-recovery-complete-at=value |
---|---|
已弃用 | 8.0.34 |
系统变量 | group_replication_recovery_complete_at |
作用范围 | 全局 |
动态 | 是 |
SET_VAR ��示适用 | 否 |
类型 | 枚举 |
默认值 | TRANSACTIONS_APPLIED |
有效值 | TRANSACTIONS_CERTIFIED``TRANSACTIONS_APPLIED |
当 Group Replication 运行时,可以更改此系统变量的值,但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_complete_at
指定了在从现有成员接收状态传输后处理缓存事务时应用的策略。您可以选择在成员接收并认证了加入组前错过的所有事务后将其标记为在线(TRANSACTIONS_CERTIFIED
),或者只有在接收、认证和应用了这些事务后才将其标记为在线(TRANSACTIONS_APPLIED
)。
此变量在 MySQL 8.0.34 中已弃用(TRANSACTIONS_CERTIFIED
也是如此)。预计在将来的 MySQL 版本中将其移除。
group_replication_recovery_compression_algorithms
命令行格式 | --group-replication-recovery-compression-algorithms=value |
---|---|
引入版本 | 8.0.18 |
系统变量 | group_replication_recovery_compression_algorithms |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 集合 |
默认值 | uncompressed |
有效数值 | zlib``zstd``uncompressed |
当 Group Replication 运行时,可以更改此系统变量的值,但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_compression_algorithms
指定了允许用于 Group Replication 分布式恢复连接的压缩算法,用于从捐赠者的二进制日志传输状态。可用的算法与 protocol_compression_algorithms
系统变量相同。有关更多信息,请参见第 6.2.8 节,“连接压缩控制”。
如果服务器已设置为支持克隆(参见第 20.5.4.2 节,“用于分布式恢复的克隆”),并且在分布式恢复期间使用远程克隆操作,则此设置不适用。对于此状态传输方法,克隆插件的 clone_enable_compression
设置适用。
group_replication_recovery_get_public_key
命令行格式 | --group-replication-recovery-get-public-key[={OFF|ON}] |
---|---|
系统变量 | group_replication_recovery_get_public_key |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 布尔值 |
默认值 | OFF |
当 Group Replication 运行时,可以更改此系统变量的值,但更改只在您停止并重新启动组复制时才会生效。
group_replication_recovery_get_public_key
指定是否从源请求用于 RSA 密钥对密码交换所需的公钥。如果 group_replication_recovery_public_key_path
设置为有效的公钥文件,则优先于 group_replication_recovery_get_public_key
。如果您未在 group_replication_recovery
通道上使用 SSL 进行分布式恢复,并且 Group Replication 的复制用户帐户使用 caching_sha2_password
插件进行身份验证(这是 MySQL 8.0 中的默认设置),则此变量适用。有关更多详细信息,请参见 第 20.6.3.1.1 节,“使用 Caching SHA-2 认证插件的复制用户”。
group_replication_recovery_public_key_path
命令行格式 | --group-replication-recovery-public-key-path=file_name |
---|---|
系统变量 | group_replication_recovery_public_key_path |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 文件名 |
默认值 | 空字符串 |
当 Group Replication 运行时,可以更改此系统变量的值,但更改只在您停止并重新启动组复制时才会生效。
group_replication_recovery_public_key_path
指定包含源端所需的用于 RSA 密钥对密码交换的公钥的副本的文件的路径名。该文件必须采用 PEM 格式。如果设置了 group_replication_recovery_public_key_path
为有效的公钥文件,则它优先于 group_replication_recovery_get_public_key
。此变量适用于在分布式恢复过程中未使用 SSL 进行 group_replication_recovery
通道(因此 group_replication_recovery_use_ssl
设置为 OFF
),并且用于 Group Replication 的复制用户帐户使用 caching_sha2_password
插件(这是 MySQL 8.0 中的默认设置)或 sha256_password
插件进行身份验证。(对于 sha256_password
,只有在使用 OpenSSL 构建 MySQL 时,设置 group_replication_recovery_public_key_path
才适用。)有关更多详细信息,请参阅 第 20.6.3.1.1 节,“使用 Caching SHA-2 认证插件的复制用户”。
group_replication_recovery_reconnect_interval
命令行格式 | --group-replication-recovery-reconnect-interval=# |
---|---|
系统变量 | group_replication_recovery_reconnect_interval |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 60 |
最小值 | 0 |
最大值 | 31536000 |
单位 | 秒 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_reconnect_interval
指定在分布式恢复过程中当组中找不到合适的提供者时重新连接尝试之间的休眠时间,单位为秒。
group_replication_recovery_retry_count
命令行格式 | --group-replication-recovery-retry-count=# |
---|---|
系统变量 | group_replication_recovery_retry_count |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 10 |
最小值 | 0 |
最大值 | 31536000 |
此系统变量的值可以在 Group Replication 运行时更改,但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。
group_replication_recovery_retry_count
指定加入的成员在放弃之前尝试连接可用捐赠者的次数。
group_replication_recovery_ssl_ca
命令行格式 | --group-replication-recovery-ssl-ca=value |
---|---|
系统变量 | group_replication_recovery_ssl_ca |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。
group_replication_recovery_ssl_ca
指定包含用于分布式恢复连接的受信任 SSL 证书颁发机构列表的文件路径。有关配置分布式恢复的 SSL 信息,请参阅 Section 20.6.2, “Securing Group Communication Connections with Secure Socket Layer (SSL)”")。
如果此服务器已设置为支持克隆(参见 Section 20.5.4.2, “Cloning for Distributed Recovery”),并且您已将 group_replication_recovery_use_ssl
设置为 ON
,Group Replication 将自动配置克隆 SSL 选项 clone_ssl_ca
的设置,以匹配您对 group_replication_recovery_ssl_ca
的设置。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
,此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_capath
命令行格式 | --group-replication-recovery-ssl-capath=value |
---|---|
系统变量 | group_replication_recovery_ssl_capath |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_capath
指定包含用于分布式恢复连接的受信任 SSL 证书颁发机构证书的目录路径。有关为分布式恢复配置 SSL 的信息,请参见 第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接” 保护组通信连接")。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
),此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_cert
命令行格式 | --group-replication-recovery-ssl-cert=value |
---|---|
系统变量 | group_replication_recovery_ssl_cert |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_cert
指定用于建立分布式恢复安全连接的 SSL 证书文件的名称。有关为分布式恢复配置 SSL 的信息,请参见 第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接” 保护组通信连接")。
如果此服务器已设置支持克隆(参见第 20.5.4.2 节,“用于分布式恢复的克隆”),并且您已将group_replication_recovery_use_ssl
设置为ON
,Group Replication 会自动配置克隆 SSL 选项clone_ssl_cert
的设置,以匹配您对group_replication_recovery_ssl_cert
的设置。
当 MySQL 通信堆栈用于组(group_replication_communication_stack = MYSQL
)时,此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_cipher
命令行格式 | --group-replication-recovery-ssl-cipher=value |
---|---|
系统变量 | group_replication_recovery_ssl_cipher |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组复制组件后才会生效。
group_replication_recovery_ssl_cipher
指定 SSL 加密的允许密码列表。有关配置分布式恢复的 SSL 信息,请参阅第 20.6.2 节,“使用安全套接字层(SSL)保护组通信连接”。
当 MySQL 通信堆栈用于组(group_replication_communication_stack = MYSQL
)时,此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_crl
命令行格式 | --group-replication-recovery-ssl-crl=value |
---|---|
系统变量 | group_replication_recovery_ssl_crl |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 文件名 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_crl
指定包含证书吊销列表文件的目录路径。参见第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接” 保护组通信连接"),了解有关为分布式恢复配置 SSL 的信息。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
),此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_crlpath
命令行格式 | --group-replication-recovery-ssl-crlpath=value |
---|---|
系统变量 | group_replication_recovery_ssl_crlpath |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 目录名称 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_crlpath
指定包含证书吊销列表文件的目录路径。参见第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接” 保护组通信连接"),了解有关为分布式恢复配置 SSL 的信息。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
),此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_key
命令行格式 | --group-replication-recovery-ssl-key=value |
---|---|
系统变量 | group_replication_recovery_ssl_key |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_key
指定用于建立安全连接的 SSL 密钥文件的名称。有关配置分布式恢复的 SSL 信息,请参阅 第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接”")。
如果此服务器已设置为支持克隆(请参阅 第 20.5.4.2 节,“用于分布式恢复的克隆”),并且您已将 group_replication_recovery_use_ssl
设置为 ON
,Group Replication 会自动配置克隆 SSL 选项 clone_ssl_key
的设置,以匹配您对 group_replication_recovery_ssl_key
的设置。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
),此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_ssl_verify_server_cert
命令行格式 | --group-replication-recovery-ssl-verify-server-cert[={OFF|ON}] |
---|---|
系统变量 | group_replication_recovery_ssl_verify_server_cert |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 布尔值 |
默认值 | OFF |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_ssl_verify_server_cert
指定分布式恢复连接是否应检查捐赠者发送的证书中服务器的通用名称值。有关配置分布式恢复的 SSL 信息,请参阅 第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接”")。
当 MySQL 通信堆栈用于组时(group_replication_communication_stack = MYSQL
),此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_tls_ciphersuites
命令行格式 | --group-replication-recovery-tls-ciphersuites=value |
---|---|
引入版本 | 8.0.19 |
系统变量 | group_replication_recovery_tls_ciphersuites |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
默认值 | NULL |
此系统变量的值可以在 Group Replication 运行时更改,但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。
group_replication_recovery_tls_ciphersuites
指定在使用 TLSv1.3 进行连接加密时,分布式恢复连接的允许密码套件的一个或多个以冒号分隔的列表,而且此服务器实例是分布式恢复连接中的客户端,即加入成员。如果在使用 TLSv1.3 时将此系统变量设置为 NULL
(如果未设置系统变量,则为默认值),则允许默认启用的密码套件,如 第 8.3.2 节,“加密连接 TLS 协议和密码” 中所列。如果将此系统变量设置为空字符串,则不允许任何密码套件,因此不使用 TLSv1.3。此系统变量从 MySQL 8.0.19 版本开始提供。有关配置分布式恢复的 SSL 信息,请参阅 第 20.6.2 节,“使用安全套接字层 (SSL) 保护组通信连接”")。
当 MySQL 通信堆栈用于组(group_replication_communication_stack = MYSQL
)时,此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
group_replication_recovery_tls_version
命令行格式 | --group-replication-recovery-tls-version=value |
---|---|
引入版本 | 8.0.19 |
系统变量 | group_replication_recovery_tls_version |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
默认值(≥ 8.0.28) | TLSv1.2,TLSv1.3 |
默认值(≥ 8.0.19,≤ 8.0.27) | TLSv1,TLSv1.1,TLSv1.2,TLSv1.3 |
此系统变量的值可以在 Group Replication 运行时更改,但更改只在您停止并重新启动组成员上的 Group Replication 后生效。
group_replication_recovery_tls_version
指定了一个逗号分隔的允许的一个或多个 TLS 协议列表,用于连接加密,当此服务器实例是分布式恢复连接中的客户端(即加入成员)时。每个分布式恢复连接中涉及的组成员作为客户端(加入成员)和服务器(捐赠者)协商它们都设置支持的最高协议版本。此系统变量从 MySQL 8.0.19 开始可用。
当 MySQL 通信堆栈用于组(group_replication_communication_stack = MYSQL
)时,此设置用于组通信连接的 TLS/SSL 配置,以及分布式恢复连接。
如果未设置此系统变量,则默认使用“TLSv1,TLSv1.1,TLSv1.2,TLSv1.3
”直到 MySQL 8.0.27,从 MySQL 8.0.28 开始,默认使用“TLSv1.2,TLSv1.3
”。确保指定的协议版本是连续的,中间没有跳过版本号。
重要
TLSv1,TLSv1.1,TLSv1.2
”,从 MySQL 8.0.28 开始为“TLSv1.2
”。
有关配置分布式恢复的 SSL 信息,请参见第 20.6.2 节,“使用安全套接字层(SSL)保护组通信连接”")��
group_replication_recovery_use_ssl
命令行格式 | --group-replication-recovery-use-ssl[={OFF|ON}] |
---|---|
系统变量 | group_replication_recovery_use_ssl |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 布尔值 |
默认值 | OFF |
此系统变量的值可以在 Group Replication 运行时更改,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_recovery_use_ssl
指定 Group Replication 组成员之间的分布式恢复连接是否应该使用 SSL。有关配置分布式恢复的 SSL 信息,请参见第 20.6.2 节,“使用安全套接字层(SSL)保护组通信连接”")。
如果此服务器已设置为支持克隆(请参阅第 20.5.4.2 节,“用于分布式恢复的克隆”),并且您将此选项设置为ON
,则 Group Replication 将使用 SSL 进行远程克隆操作以及从捐赠者的二进制日志传输状态。如果将此选项设置为OFF
,则 Group Replication 不会使用 SSL 进行远程克隆操作。
group_replication_recovery_zstd_compression_level
命令行格式 | --group-replication-recovery-zstd-compression-level=# |
---|---|
引入版本 | 8.0.18 |
系统变量 | group_replication_recovery_zstd_compression_level |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 3 |
最小值 | 1 |
最大值 | 22 |
在 Group Replication 运行时可以更改此系统变量的值,但更改只有在停止并重新启动组复制时才会生效。
group_replication_recovery_zstd_compression_level
指定用于使用zstd
压缩算法的 Group Replication 分布式恢复连接的压缩级别。允许的级别从 1 到 22,较大的值表示较高级别的压缩。默认的zstd
压缩级别为 3。对于不使用zstd
压缩的分布式恢复连接,此变量不起作用。
更多信息,请参阅 第 6.2.8 节,“连接压缩控制”。
group_replication_single_primary_mode
命令行格式 | --group-replication-single-primary-mode[={OFF|ON}] |
---|---|
系统变量 | group_replication_single_primary_mode |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 布尔值 |
默认值 | ON |
注意
此系统变量是一个组范围的配置设置,需要完全重新启动复制组才能使更改生效。
group_replication_single_primary_mode
指示组自动选择一个服务器作为处理读/写工作负载的主服务器。这个服务器是主服务器,其他所有服务器都是从服务器。
此系统变量是一个组范围的配置设置。它必须在所有组成员上具有相同的值,不能在组复制运行时更改,并且需要对组进行完全重新启动(由具有group_replication_bootstrap_group=ON
的服务器引导)以使值更改生效。有关在已执行和认证事务的组中安全引导组的说明,请参见第 20.5.2 节,“重新启动组”。
如果组为此系统变量设置了一个值,并且加入的成员为该系统变量设置了不同的值,则加入的成员在值匹配之前无法加入该组。如果组成员为此系统变量设置了一个值,而加入的成员不支持该系统变量,则无法加入该组。
将此变量设置为ON
会导致group_replication_auto_increment_increment
的任何设置被忽略。
在 MySQL 8.0.16 及更高版本中,您可以使用group_replication_switch_to_single_primary_mode()
和group_replication_switch_to_multi_primary_mode()
函数在组仍在运行时更改此系统变量的值。有关更多信息,请参见第 20.5.1.2 节,“更改组模式”。
group_replication_ssl_mode
命令行格式 | --group-replication-ssl-mode=value |
---|---|
系统变量 | group_replication_ssl_mode |
范围 | 全局 |
动态 | 是 |
SET_VAR提示适用 | 否 |
类型 | 枚举 |
默认值 | DISABLED |
有效值 | DISABLED``REQUIRED``VERIFY_CA``VERIFY_IDENTITY |
可以在组复制运行时更改此系统变量的值,但更改只有在停止并重新启动组复制后才会生效。
group_replication_ssl_mode
设置了组复制成员之间组通信连接的安全状态。可能的值如下:
DISABLED
建立一个未加密的连接(默认值)。
REQUIRED
如果服务器支持安全连接,则建立安全连接。
VERIFY_CA
类似于 REQUIRED
,但还根据配置的证书颁发机构(CA)证书验证服务器 TLS 证书。
VERIFY_IDENTITY
类似于 VERIFY_CA
,但还验证服务器证书是否与尝试连接的主机匹配。
请参阅 第 20.6.2 节,“使用安全套接字层(SSL)保护组通信连接” 以获取有关为组通信配置 SSL 的信息。
group_replication_start_on_boot
命令行格式 | --group-replication-start-on-boot[={OFF|ON}] |
---|---|
系统变量 | group_replication_start_on_boot |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 布尔值 |
默认值 | ON |
此系统变量的值可以在 Group Replication 运行���更改,但更改仅在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_start_on_boot
指定服务器在启动时是否应自动启动 Group Replication(ON
)或不启动(OFF
)。当您将此选项设置为 ON
时,在使用远程克隆操作进行分布式恢复后,Group Replication 将自动重新启动。
要在服务器启动时自动启动 Group Replication,必须使用 CHANGE MASTER TO
语句将分布式恢复的用户凭据存储在服务器上的复制元数据存储库中。如果您希望在 START GROUP_REPLICATION
语句中指定用户凭据,该语句仅将用户凭据存储在内存中,请确保 group_replication_start_on_boot
设置为 OFF
。
group_replication_tls_source
命令行格式 | --group-replication-tls-source=value |
---|---|
引入版本 | 8.0.21 |
系统变量 | group_replication_tls_source |
作用范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 枚举 |
默认值 | mysql_main |
有效值 | mysql_main``mysql_admin |
在 Group Replication 运行时可以更改此系统变量的值,但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
group_replication_tls_source
指定了 Group Replication 的 TLS 材料来源。
group_replication_transaction_size_limit
命令行格式 | --group-replication-transaction-size-limit=# |
---|---|
系统变量 | group_replication_transaction_size_limit |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 150000000 |
最小值 | 0 |
最大值 | 2147483647 |
单位 | 字节 |
此系统变量在所有组成员上应具有相同的值。在 Group Replication 运行时可以更改此系统变量的值。更改立即在组成员上生效,并且从该成员上启动的下一个事务开始应用。在此过程中,系统变量的值允许在组成员之间有所不同,但某些事务可能会被拒绝。
group_replication_transaction_size_limit
配置了复制组接受的最大事务大小(以字节为单位)。大于此大小的事务将被接收成员回滚,并且不会广播到组中。大事务可能会导致复制组在内存分配方面出现问题,这可能导致系统变慢,或者在网络带宽消耗方面出现问题,这可能导致成员被怀疑已经失败,因为它正忙于处理大事务。
当此系统变量设置为 0 时,组接受的事务大小没有限制。从 MySQL 8.0 开始,此系统变量的默认设置为 150000000 字节(约为 143 MB)。根据组需要容忍的最大消息大小调整此系统变量的值,要记住,处理事务所需的时间与其大小成正比。group_replication_transaction_size_limit
的值应在所有组成员上相同。有关大事务的进一步缓解策略,请参见 第 20.3.2 节,“Group Replication 限制”。
group_replication_unreachable_majority_timeout
命令行格式 | --group-replication-unreachable-majority-timeout=# |
---|---|
系统变量 | group_replication_unreachable_majority_timeout |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 31536000 |
单元 | 秒 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。当发生需要该行为的问题时,会读取系统变量的当前值。
group_replication_unreachable_majority_timeout
指定了成员在遭受网络分区且无法连接到多数派时等待离开组的秒数。在一个由 5 台服务器(S1,S2,S3,S4,S5)组成的组中,如果在(S1,S2)和(S3,S4,S5)之间存在断开连接,则存在网络分区。第一组(S1,S2)现在处于少数派,因为它无法联系到超过一半的组。而多数派组(S3,S4,S5)仍在运行,少数派组等待指定的时间进行网络重新连接。有关此场景的详细描述,请参见第 20.7.8 节,“处理网络分区和丢失法定人数”。
默认情况下,group_replication_unreachable_majority_timeout
设置为 0,这意味着由于网络分区而发现自己处于少数派的成员将永远等待离开组。如果设置了超时时间,当指定时间到达时,少数派处理的所有待处理事务都将被回滚,并且少数派分区中的服务器将移至ERROR
状态。如果成员的 group_replication_autorejoin_tries
系统变量设置了指定的自动重新加入尝试次数,它将在超级只读模式下进行指定次数的重新加入尝试。如果成员没有指定任何自动重新加入尝试,或者已经耗尽了指定次数的尝试次数,则会按照系统变量 group_replication_exit_state_action
指定的操作进行。
警告
当你有一个对称的组,例如只有两个成员(S0,S2),如果存在网络分区且没有多数派,在配置的超时时间后,所有成员都会进入ERROR
状态。
欲了解更多关于此选项的信息,请参阅 第 20.7.7.2 节,“无法达到多数超时”。
group_replication_view_change_uuid
命令行格式 | --group-replication-view-change-uuid=value |
---|---|
引入版本 | 8.0.26 |
系统变量 | group_replication_view_change_uuid |
作用域 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
默认值 | AUTOMATIC |
注意
这个系统变量是一个整个组的配置设置,需要对复制组进行完全重启才能使更改生效。
group_replication_view_change_uuid
指定一个替代 UUID,用作组生成的视图更改事件中 GTID 标识符的 UUID 部分。替代 UUID 使这些内部生成的事务易于与从客户端接收的事务区分开。如果您的设置允许在组之间进行故障切换,并且您需要识别和丢弃特定于备份组的事务,则这可能很有用。此系统变量的默认值为 AUTOMATIC
,意味着视图更改事件的 GTID 使用由 group_replication_group_name
系统变量指定的组名,就像来自客户端的事务一样。在没有此系统变量的版本中,组成员被视为具有值 AUTOMATIC
。
替代 UUID 必须与由 group_replication_group_name
系统变量指定的组名不同,并且必须与任何组成员的服务器 UUID 不同。它还必须与应用于拓扑中任何复制通道上的匿名事务的 GTID 中使用的任何 UUID 不同,使用 CHANGE REPLICATION SOURCE TO
语句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项。
这个系统变量是一个群组范围的配置设置。它必须在所有群组成员上具有相同的数值,不能在 Group Replication 运行时更改,并且需要对群组进行完全重启(由具有 group_replication_bootstrap_group=ON
的服务器引导)以使数值更改生效。有关在已执行和认证事务的群组中安全引导群组的说明,请参见 Section 20.5.2, “Restarting a Group”。
如果群组对这个系统变量有一个数值设置,而加入的成员对这个系统变量有一个不同的数值设置,那么加入的成员在数值匹配之前无法加入群组。如果群组成员对这个系统变量有一个数值设置,而加入的成员不支持这个系统变量,那么它无法加入群组。 t`
命令行格式 | --group-replication-transaction-size-limit=# |
---|---|
系统变量 | group_replication_transaction_size_limit |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 150000000 |
最小值 | 0 |
最大值 | 2147483647 |
单位 | 字节 |
此系统变量在所有组成员上应具有相同的值。在 Group Replication 运行时可以更改此系统变量的值。更改立即在组成员上生效,并且从该成员上启动的下一个事务开始应用。在此过程中,系统变量的值允许在组成员之间有所不同,但某些事务可能会被拒绝。
group_replication_transaction_size_limit
配置了复制组接受的最大事务大小(以字节为单位)。大于此大小的事务将被接收成员回滚,并且不会广播到组中。大事务可能会导致复制组在内存分配方面出现问题,这可能导致系统变慢,或者在网络带宽消耗方面出现问题,这可能导致成员被怀疑已经失败,因为它正忙于处理大事务。
当此系统变量设置为 0 时,组接受的事务大小没有限制。从 MySQL 8.0 开始,此系统变量的默认设置为 150000000 字节(约为 143 MB)。根据组需要容忍的最大消息大小调整此系统变量的值,要记住,处理事务所需的时间与其大小成正比。group_replication_transaction_size_limit
的值应在所有组成员上相同。有关大事务的进一步缓解策略,请参见 第 20.3.2 节,“Group Replication 限制”。
group_replication_unreachable_majority_timeout
命令行格式 | --group-replication-unreachable-majority-timeout=# |
---|---|
系统变量 | group_replication_unreachable_majority_timeout |
范围 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 整数 |
默认值 | 0 |
最小值 | 0 |
最大值 | 31536000 |
单元 | 秒 |
此系统变量的值可以在 Group Replication 运行时更改,并立即生效。当发生需要该行为的问题时,会读取系统变量的当前值。
group_replication_unreachable_majority_timeout
指定了成员在遭受网络分区且无法连接到多数派时等待离开组的秒数。在一个由 5 台服务器(S1,S2,S3,S4,S5)组成的组中,如果在(S1,S2)和(S3,S4,S5)之间存在断开连接,则存在网络分区。第一组(S1,S2)现在处于少数派,因为它无法联系到超过一半的组。而多数派组(S3,S4,S5)仍在运行,少数派组等待指定的时间进行网络重新连接。有关此场景的详细描述,请参见第 20.7.8 节,“处理网络分区和丢失法定人数”。
默认情况下,group_replication_unreachable_majority_timeout
设置为 0,这意味着由于网络分区而发现自己处于少数派的成员将永远等待离开组。如果设置了超时时间,当指定时间到达时,少数派处理的所有待处理事务都将被回滚,并且少数派分区中的服务器将移至ERROR
状态。如果成员的 group_replication_autorejoin_tries
系统变量设置了指定的自动重新加入尝试次数,它将在超级只读模式下进行指定次数的重新加入尝试。如果成员没有指定任何自动重新加入尝试,或者已经耗尽了指定次数的尝试次数,则会按照系统变量 group_replication_exit_state_action
指定的操作进行。
警告
当你有一个对称的组,例如只有两个成员(S0,S2),如果存在网络分区且没有多数派,在配置的超时时间后,所有成员都会进入ERROR
状态。
欲了解更多关于此选项的信息,请参阅 第 20.7.7.2 节,“无法达到多数超时”。
group_replication_view_change_uuid
命令行格式 | --group-replication-view-change-uuid=value |
---|---|
引入版本 | 8.0.26 |
系统变量 | group_replication_view_change_uuid |
作用域 | 全局 |
动态 | 是 |
SET_VAR 提示适用 | 否 |
类型 | 字符串 |
默认值 | AUTOMATIC |
注意
这个系统变量是一个整个组的配置设置,需要对复制组进行完全重启才能使更改生效。
group_replication_view_change_uuid
指定一个替代 UUID,用作组生成的视图更改事件中 GTID 标识符的 UUID 部分。替代 UUID 使这些内部生成的事务易于与从客户端接收的事务区分开。如果您的设置允许在组之间进行故障切换,并且您需要识别和丢弃特定于备份组的事务,则这可能很有用。此系统变量的默认值为 AUTOMATIC
,意味着视图更改事件的 GTID 使用由 group_replication_group_name
系统变量指定的组名,就像来自客户端的事务一样。在没有此系统变量的版本中,组成员被视为具有值 AUTOMATIC
。
替代 UUID 必须与由 group_replication_group_name
系统变量指定的组名不同,并且必须与任何组成员的服务器 UUID 不同。它还必须与应用于拓扑中任何复制通道上的匿名事务的 GTID 中使用的任何 UUID 不同,使用 CHANGE REPLICATION SOURCE TO
语句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项。
这个系统变量是一个群组范围的配置设置。它必须在所有群组成员上具有相同的数值,不能在 Group Replication 运行时更改,并且需要对群组进行完全重启(由具有 group_replication_bootstrap_group=ON
的服务器引导)以使数值更改生效。有关在已执行和认证事务的群组中安全引导群组的说明,请参见 Section 20.5.2, “Restarting a Group”。
如果群组对这个系统变量有一个数值设置,而加入的成员对这个系统变量有一个不同的数值设置,那么加入的成员在数值匹配之前无法加入群组。如果群组成员对这个系统变量有一个数值设置,而加入的成员不支持这个系统变量,那么它无法加入群组。