MySQL 8.3 Release Notes
状态传输从二进制日志需要一个具有正确权限的复制用户，以便Group Replication可以建立直接成员到成员的复制通道。同一个复制用户用于所有组成员的分布式恢复。如果组成员已经设置了支持远程克隆操作作为分布式恢复的一部分，这个复制用户也将用作donor上的克隆用户，并需要正确的权限来执行此角色。有关设置此用户的详细说明，请参阅第 20.2.1.3 节，“用户凭证For Distributed Recovery”。
要保护用户凭证，可以要求使用SSL连接用户账户，并在启动Group Replication时提供用户凭证，而不是将其存储在副本状态表中。此外，如果您使用缓存SHA-2身份验证，还需要在组成员上设置RSA密钥对。
Important
使用MySQL通信栈（group_replication_communication_stack=MYSQL）AND安全成员之间的连接（group_replication_ssl_mode未设置为DISABLED），恢复用户必须正确设置，因为它们也是组通信的用户。按照第 20.6.3.1.2 节，“使用SSL的复制用户”和第 20.6.3.1.3 节，“安全地提供复制用户凭证”中的说明进行设置。
默认情况下，MySQL 8 中创建的用户使用第 8.4.1.2 节，“Caching SHA-2可插拔身份验证”。如果您为分布式恢复配置的复制用户使用Caching SHA-2身份验证插件，并且您不使用SSL连接分布式恢复连接，那么RSA密钥对将用于密码交换。有关RSA密钥对的更多信息，请参阅第 8.3.3 节，“创建SSL和RSA证书和密钥”。
在这种情况下，您可以将rpl_user的公钥复制到加入成员，或者配置donor提供公钥时请求。更安全的方法是将复制用户账户的公钥复制到加入成员。然后，您需要在加入成员上配置group_replication_recovery_public_key_path系统变量，以便指定复制用户账户的公钥路径。
较不安全的方法是将group_replication_recovery_get_public_key=ON设置在donor上，以便它们提供复制用户账户的公钥给加入成员。由于无法验证服务器的身份，因此只有在您确定没有服务器身份被篡改的风险时，例如通过中间人攻击，才设置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;
Note
使用 MySQL 通信栈 (group_replication_communication_stack=MYSQL) 和安全连接之间的成员 (group_replication_ssl_mode 未设置为 DISABLED) 时，需要 GROUP_REPLICATION_STREAM 权限。请参阅 第 20.6.1 节，“通信栈用于连接安全管理”。
要提供复制用户的凭证，可以永久地将其设置为 group_replication_recovery 通道的凭证，使用 CHANGE REPLICATION SOURCE TO 语句。或者，可以在每次启动 Group Replication 时在 START GROUP_REPLICATION 语句中指定它们。在 START GROUP_REPLICATION 中指定的用户凭证优先于使用 CHANGE REPLICATION SOURCE TO 语句设置的用户凭证。
使用 CHANGE REPLICATION SOURCE TO 设置的用户凭证将以明文形式存储在服务器的复制元数据存储库中，但是在 START GROUP_REPLICATION 中指定的用户凭证将仅存储在内存中，并将在 STOP GROUP_REPLICATION 语句或服务器关闭时删除。因此，使用 START GROUP_REPLICATION 指定用户凭证可以帮助保护 Group Replication 服务器免受未经授权的访问。但是，这种方法与自动启动 Group Replication 不兼容，如 group_replication_start_on_boot 系统变量所指定的那样。
如果您想永久地使用 CHANGE REPLICATION SOURCE TO 语句设置用户凭证，请在要加入组的成员上发出该语句：
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rec_ssl_user',
-> SOURCE_PASSWORD='password'
-> FOR CHANNEL 'group_replication_recovery';要在 START GROUP_REPLICATION 中指定用户凭证，请在首次启动 Group Replication 或服务器重启时发出该语句：
mysql> START GROUP_REPLICATION USER='rec_ssl_user', PASSWORD='password';
Important
如果您从使用 CHANGE REPLICATION SOURCE TO 语句提供用户凭证切换到使用 START GROUP_REPLICATION 语句指定用户凭证的服务器，请完成以下步骤以获取该更改的安全优势。
-
使用
STOP GROUP_REPLICATION语句停止组成员上的 Group Replication。虽然可以在 Group Replication 运行时执行以下两个步骤，但需要重新启动 Group Replication 以实施更改。 -
将
group_replication_start_on_boot系统变量的值设置为OFF（默认值为ON）。 -
从复制状态表中删除分布式恢复凭证，发出以下语句：
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='', SOURCE_PASSWORD='' -> FOR CHANNEL 'group_replication_recovery'; -
使用指定分布式恢复用户凭证的
START GROUP_REPLICATION语句重新启动组成员上的 Group Replication。
如果不执行这些步骤，凭证将保留在副本状态表中，并且可以在分布式恢复操作期间传输到其他组成员中。在远程克隆操作期间，group_replication_recovery 通道可能会意外启动，使用存储的凭证，either 在原始成员或从其克隆的成员上。服务器启动时（包括远程克隆操作后）的自动启动组复制将使用存储的用户凭证，如果操作员没有指定分布式恢复凭证作为START GROUP_REPLICATION的一部分。