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

版本 8.4

9.0
8.0

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

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

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

使用其自身的安全性协议实现，包括 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 服务器配置文件（通常在 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 权限。您需要将组成员从组复制停止时应用的只读状态中移除。同时，请确保通过在发出 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 的情况下默认为）以前通信堆栈的服务器将无法再加入组。重要的是要注意，由于组复制甚至无法看到加入尝试，因此不会检查并拒绝加入成员并显示错误消息。相反，当以前的通信堆栈放弃尝试联系新的通信堆栈时，加入尝试将静默失败。