MySQL :: MySQL 9.0 参考手册 :: 20.6.1 连接安全管理的通信堆栈

版本 9.0

8.4 当前
8.0

MySQL 9.0 参考手册 / ... / 用于连接安全管理的通信堆栈

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

MySQL 9.0 组复制可以通过以下方法之一保护成员之间的组通信连接。

使用其自身的安全性协议实现，包括 TLS/SSL 和对传入组通信系统 (GCS) 连接的允许列表的使用。
使用 MySQL 服务器自己的连接安全性来代替组复制的实现。使用 MySQL 协议意味着可以使用标准的用户身份验证方法来授予（或撤销）对组的访问权限，而不是使用允许列表，并且服务器协议的最新功能始终在发布时可用。

通过将系统变量 group_replication_communication_stack 设置为 XCOM 来使用组复制自己的实现（这是默认选择），或者设置为 MYSQL 来使用 MySQL 服务器的连接安全性。

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

MySQL 通信堆栈的组复制要求

每个组成员的 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 通信堆栈时，TLS/SSL 配置取自组复制的分布式恢复设置。此设置应在所有组成员上保持一致，以避免潜在冲突。
所有组成员的 require_secure_transport 服务器系统变量值应保持一致，以避免潜在冲突。如果 group_replication_ssl_mode 设置为 REQUIRED、VERIFY_CA 或 VERIFY_IDENTITY，请使用 require_secure_transport=ON。如果 group_replication_ssl_mode 设置为 DISABLED，请使用 require_secure_transport=OFF。
如果为组通信启用了 TLS/SSL，则必须配置组复制的用于保护分布式恢复的设置（如果它们尚未到位），或者如果它们已到位则进行验证。MySQL 通信堆栈不仅使用这些设置用于成员到成员的分布式恢复连接，还用于一般组通信中的 TLS/SSL 配置。 group_replication_recovery_use_ssl 和其他 group_replication_recovery_* 系统变量在第 20.6.3.2 节，“用于分布式恢复的安全套接字层 (SSL) 连接” 中进行了说明。
当组使用 MySQL 通信堆栈时，不会使用组复制允许列表，因此 group_replication_ip_allowlist 系统变量将被忽略，无需设置。
组复制用于分布式恢复的复制用户帐户（使用 CHANGE REPLICATION SOURCE TO 语句配置）用于在设置组复制连接时由 MySQL 通信堆栈进行身份验证。此用户帐户（在所有组成员上都相同）必须具有以下权限。
- GROUP_REPLICATION_STREAM。该权限对于用户帐户能够使用 MySQL 通信堆栈建立组复制连接是必需的。
- CONNECTION_ADMIN。该权限对于防止在涉及的服务器之一处于脱机模式时终止组复制连接是必需的。如果在没有此权限的情况下使用 MySQL 通信堆栈，则处于脱机模式的成员将被驱逐出组。
除了所有复制用户帐户都必须具有的 REPLICATION SLAVE 和 BACKUP_ADMIN 权限外（参见第 20.2.1.3 节，“用于分布式恢复的用户凭据”），在添加新权限时，请确保通过在发出 GRANT 语句之前发出 SET SQL_LOG_BIN=0，并在之后发出 SET SQL_LOG_BIN=1，在每个组成员上跳过二进制日志记录，这样本地事务就不会干扰重新启动组复制。

group_replication_communication_stack 实际上是一个组范围的配置设置，并且该设置必须在所有组成员上相同。但是，这不受组复制自身对组范围配置设置检查的约束。具有与组中其他成员不同的值的成员根本无法与其他成员通信，因为通信协议不兼容，因此它无法交换有关其配置设置的信息。

这意味着，虽然可以在组复制运行时更改系统变量的值，并在您在组成员上重新启动组复制后生效，但该成员仍然无法重新加入组，直到在所有成员上更改了该设置。因此，您必须停止所有成员上的组复制，并在所有成员上更改系统变量的值，然后才能重新启动组。由于所有成员都已停止，因此需要完全重新启动组（由具有 group_replication_bootstrap_group=ON 的服务器引导）才能使值更改生效。您可以在组成员停止时对组成员上的其他必要设置进行更改。

对于运行中的组，请按照以下步骤更改 group_replication_communication_stack 的值以及其他必要设置，以将组从 XCom 通信堆栈迁移到 MySQL 通信堆栈，或从 MySQL 通信堆栈迁移到 XCom 通信堆栈。

使用 STOP GROUP_REPLICATION 语句停止每个组成员上的组复制。最后停止主成员，这样您就不会触发新的主成员选举，也不必等待选举完成。
在每个组成员上，将系统变量 group_replication_communication_stack 设置为新的通信堆栈，即 MYSQL 或 XCOM，具体取决于您的需要。您可以通过编辑 MySQL Server 配置文件（通常在 Linux 和 Unix 系统上名为 my.cnf，在 Windows 系统上名为 my.ini）或使用 SET 语句来执行此操作。例如
```
SET PERSIST group_replication_communication_stack="MYSQL";
```
如果您要将复制组从 XCom 通信堆栈（默认值）迁移到 MySQL 通信堆栈，则在每个组成员上，按照上面的列表将所需的系统变量配置或重新配置为适当的设置。例如，group_replication_local_address 系统变量必须设置为 MySQL Server 正在侦听的 IP 地址和端口之一。还要使用 CHANGE REPLICATION SOURCE TO 语句配置任何网络命名空间。
如果您要将复制组从 XCom 通信堆栈（默认值）迁移到 MySQL 通信堆栈，则在每个组成员上，发出 GRANT 语句，以便为复制用户帐户提供 GROUP_REPLICATION_STREAM 和 CONNECTION_ADMIN 权限。您需要将组成员从停止组复制时应用的只读状态中移除。还要确保通过在发出 GRANT 语句之前发出 SET SQL_LOG_BIN=0，并在之后发出 SET SQL_LOG_BIN=1，在每个组成员上跳过二进制日志记录，这样本地事务就不会干扰重新启动组复制。例如
```
SET GLOBAL SUPER_READ_ONLY=OFF;
SET SQL_LOG_BIN=0; 
GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;
```
如果您要将复制组从 MySQL 通信堆栈迁移回 XCom 通信堆栈，则在每个组成员上，将上面的需求列表中的系统变量重新配置为适合 XCom 通信堆栈的设置。第 20.9 节，“组复制变量” 列出了具有默认值和 XCom 通信堆栈要求的系统变量。
注意
- XCom 通信堆栈不支持网络命名空间，因此组复制本地地址（group_replication_local_address 系统变量）不能使用这些命名空间。通过发出 CHANGE REPLICATION SOURCE TO 语句将其取消设置。
- 当您迁移回 XCom 通信堆栈时，由 group_replication_recovery_use_ssl 和其他 group_replication_recovery_* 系统变量指定的设置不会用于保护组通信。相反，组复制系统变量 group_replication_ssl_mode 用于激活对组通信连接使用 SSL 并指定连接的安全模式，其余配置则从服务器的 SSL 配置中获取。有关详细信息，请参见第 20.6.2 节，“使用安全套接字层 (SSL) 保护组通信连接”。
要重新启动组，请按照第 20.5.2 节，“重新启动组” 中的步骤操作，其中介绍了如何在已执行和认证事务的情况下安全地引导组。需要由具有 group_replication_bootstrap_group=ON 的服务器进行引导，因为所有成员都必须关闭。
成员现在使用新的通信堆栈相互连接。任何 group_replication_communication_stack 设置为（或在 XCom 的情况下默认设置为）先前通信堆栈的服务器将无法再加入组。请注意，由于组复制甚至无法看到加入尝试，因此它不会检查并拒绝加入的成员，也不会显示错误消息。相反，加入尝试会以静默方式失败，因为先前通信堆栈放弃了尝试联系新的通信堆栈。