MySQL8 中文参考（八十二）（1）

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

20.6 组复制安全性

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

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

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

20.6.3 保护分布式恢复连接

20.6.4 组复制 IP 地址权限

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

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

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

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

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

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

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

MySQL 通信堆栈的 Group Replication 要求

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

• GROUP_REPLICATION_STREAM。此权限是用户帐户能够使用 MySQL 通信堆栈建立 Group Replication 连接所必需的。
  
• CONNECTION_ADMIN。此权限是为了确保 Group Replication 连接在涉及的服务器之一处于离线模式时不会被终止。如果使用 MySQL 通信堆栈而没有此权限，则被放置在离线模式的成员将被从组中驱逐。
  

• 这些权限是所有复制用户帐户必须具有的权限REPLICATION SLAVE和BACKUP_ADMIN的附加权限（请参阅第 20.2.1.3 节，“用于分布式恢复的用户凭据”）。在添加新权限时，请确保在发出GRANT语句之前通过发出SET SQL_LOG_BIN=0跳过每个组成员上的二进制日志记录，并在之后通过SET SQL_LOG_BIN=1，以便本地事务不会干扰 Group Replication 的重新启动。
  

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

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

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

1. 在每个群组成员上停止 Group Replication，使用STOP GROUP_REPLICATION语句。最后停止主要成员，以免触发新的主要选举并等待其完成。
   
2. 在每个群组成员上，将系统变量group_replication_communication_stack设置为新的通信栈，MYSQL或XCOM，具体取决于情况。您可以通过编辑 MySQL 服务器配置文件（在 Linux 和 Unix 系统上通常命名为my.cnf，在 Windows 系统上为my.ini），或使用SET语句来完成。例如：

SET PERSIST group_replication_communication_stack="MYSQL";

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

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

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

2. 要重新启动组，请按照第 20.5.2 节“重新启动组”中的过程进行操作，该节解释了如何安全地引导已执行和认证事务的组。由具有group_replication_bootstrap_group=ON的服务器引导是必要的，以更改通信堆栈，因为所有成员必须关闭。
   
3. 成员现在使用新的通信堆栈相互连接。任何将group_replication_communication_stack设置为先前通信堆栈（或在 XCom 的情况下默认设置）的服务器将无法加入该组。重要的是要注意，由于组复制甚至无法看到加入尝试，因此它不会检查并用错误消息拒绝加入成员。相反，当先前的通信堆栈放弃尝试联系新的通信堆栈时，尝试加入会悄无声息地失败。
   

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

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

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

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

表 20.1 group_replication_ssl_mode 配置值

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

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

表 20.2 SSL 选项

重要提示

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

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

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

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

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

重要提示

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

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

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

20.6.3 保护分布式恢复连接

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

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

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

重要提示

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

20.6.3.1.2 带 SSL 的复制用户

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

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

注意

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

20.6.3.1.3 安全提供复制用户凭据

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

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

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

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

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

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

重要提示

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

1. 使用STOP GROUP_REPLICATION语句在组成员上停止组复制。虽然在组复制运行时可以执行以下两个步骤，但需要重新启动组复制以实施更改。
   
2. 将group_replication_start_on_boot系统变量的值设置为OFF（默认为ON）。
   
3. 通过发出以下语句从副本状态表中删除分布式恢复凭据：

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';

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

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

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

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

重要

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

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

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

分布式恢复 SSL 选项如下：

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

20.6.4 组复制 IP 地址权限

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

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

注意

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

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

IPv4 (as defined in RFC 1918)
10/8 prefix       (10.0.0.0 - 10.255.255.255) - Class A
172.16/12 prefix  (172.16.0.0 - 172.31.255.255) - Class B
192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class C
IPv6 (as defined in RFC 4193 and RFC 5156)
fc00:/7 prefix    - unique-local addresses
fe80::/10 prefix  - link-local unicast addresses
127.0.0.1 - localhost for IPv4
::1       - localhost for IPv6

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

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

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

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

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

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

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

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

注意

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

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

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

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

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

注意

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

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

警告

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

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

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

20.7.1 调整群组通信线程

20.7.2 流量控制

20.7.3 单一共识领导者

20.7.4 消息压缩

20.7.5 消息分段

20.7.6 XCom 缓存管理

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

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

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

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

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

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

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

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

20.7.1 优化组通信线程

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

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

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

例如：

mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;

20.7.2 流量控制

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

20.7.2.1 探针和统计信息

20.7.2.2 Group Replication 限流

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

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

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

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

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

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

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

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

20.7.2.1 探针和统计信息

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

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

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

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

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

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

20.7.2.2 组复制限流

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

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

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

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

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

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

MySQL8 中文参考（八十二）（2）https://developer.aliyun.com/article/1565902