Securing Distributed Recovery Connections MySQL 8.0.21, group members may advertise an alternative list of distributed recovery endpoints as dedicated client connections for joining members. For more details, see Section 18.5.3.1, “Connections for Distributed Recovery” . To secure distributed recovery connections in the group, ensure that user credentials for the replication user are properly secured, and use SSL for distributed recovery connections if possible. State transfer from the binary log requires a replication user with the correct permissions so that Group Replication can establish direct member-to-member replication channels. The same replication user is used for distributed recovery on all the group members. If group members have been set up to support the use of a remote cloning operation as part of distributed recovery, which is available from MySQL 8.0.17, this replication user is also used as the clone user on the donor, and requires the correct permissions for this role too. For detailed instructions to set up this user, see Section 18.2.1.3, “User Credentials For Distributed Recovery” . To secure the user credentials, you can require SSL for connections with the user account, and (from MySQL 8.0.21) you can provide the user credentials when Group Replication is started, rather than storing them in the replica status tables. Also, if you are using caching SHA-2 authentication, you must set up RSA key-pairs on the group members. By default, users created in MySQL 8 use Section 6.4.1.2, “Caching SHA-2 Pluggable Authentication” . If the replication user you configure for distributed recovery uses the caching SHA-2 authentication plugin, and you are  not  using SSL for distributed recovery connections, RSA key-pairs are used for password exchange. For more information on RSA key-pairs, see Section 6.3.3, “Creating SSL and RSA Certificates and Keys” . In this situation, you can either copy the public key of the  rpl_user  to the joining member, or configure the donors to provide the public key when requested. The more secure approach is to copy the public key of the replication user account to the joining member. Then you need to configure the group_replication_recovery_public_key_path  system variable on the joining member with the path to the public key for the replication user account. The less secure approach is to set  group_replication_recovery_get_public_key=ON on donors so that they provide the public key of the replication user account to joining members. There is no way to verify the identity of a server, therefore only set group_replication_recovery_get_public_key=ON  when you are sure there is no risk of server identity being compromised, for example by a man-in-the-middle attack. A replication user that requires an SSL connection must be created  before  the server joining the group (the joining member) connects to the donor. Typically, this is set up at the time you are provisioning a server to join the group. To create a replication user for distributed recovery that requires an SSL connection, issue these statements on all servers that are going to participate in the group: 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 BACKUP_ADMIN ON *.* TO ’ rec_ssl_user ’@’%’; mysql>  FLUSH PRIVILEGES; mysql>  SET SQL_LOG_BIN=1; 3770 Replication User With SSL Replication User With The Caching SHA-2 Authentication Plugin 18.6.3.1 Secure User Credentials for Distributed Recovery