Cloning for Other Purposes 18.5.3.3 Configuring Distributed Recovery Number of Connection Attempts 3743 Distributed Recovery also preserves the channel settings that relate to the use of SSL, so these are unique to the individual member. If the replication user credentials used by the donor for the  group_replication_recovery  replication channel have been stored in the replication metadata repositories using a  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  statement, they are transferred to and used by the joining member after cloning, and they must be valid there. With stored credentials, all group members that received state transfer by a remote cloning operation therefore automatically receive the replication user and password for distributed recovery. If you specify the replication user credentials on the  START GROUP_REPLICATION  statement, these are used to start the remote cloning operation, but they are not transferred to and used by the joining member after cloning. If you do not want the credentials transferred to new joiners and recorded there, ensure that you unset them before remote cloning operations take place, as described in Section 18.6.3, “Securing Distributed Recovery Connections” , and use  START GROUP_REPLICATION  to supply them instead. If a  PRIVILEGE_CHECKS_USER  account has been used to help secure the replication appliers (see Section 17.3.3.2, “Privilege Checks For Group Replication Channels” ), from MySQL 8.0.19, the PRIVILEGE_CHECKS_USER  account and related settings from the donor are cloned to the joining member. If the joining member is set to start Group Replication on boot, it automatically uses the account for privilege checks on the appropriate replication channels. (In MySQL 8.0.18, due to a number of limitations, it is recommended that you do not use a  PRIVILEGE_CHECKS_USER  account with Group Replication channels.) Group Replication initiates and manages cloning operations for distributed recovery. Group members that have been set up to support cloning may also participate in cloning operations that a user initiates manually. For example, you might want to create a new server instance by cloning from a group member as the donor, but you do not want the new server instance to join the group immediately, or maybe not ever. In all releases that support cloning, you can initiate a cloning operation manually involving a group member on which Group Replication is stopped. Note that because cloning requires that the active plugins on a donor and recipient must match, the Group Replication plugin must be installed and active on the other server instance, even if you do not intend that server instance to join a group. You can install the plugin by issuing this statement: INSTALL PLUGIN group_replication SONAME ’group_replication.so’; In releases before MySQL 8.0.20, you cannot initiate a cloning operation manually if the operation involves a group member on which Group Replication is running. From MySQL 8.0.20, you can do this, provided that the cloning operation does not remove and replace the data on the recipient. The statement to initiate the cloning operation must therefore include the  DATA DIRECTORY  clause if Group Replication is running. Several aspects of Group Replication’s distributed recovery process can be configured to suit your system. For state transfer from the binary log, Group Replication limits the number of attempts a joining member makes when trying to connect to a donor from the pool of donors. If the connection retry limit is reached without a successful connection, the distributed recovery procedure terminates with an error. Note that this limit specifies the total number of attempts that the joining member makes to connect to a donor. For example, if 2 group members are suitable donors, and the connection retry limit is set to 4, the joining member makes 2 attempts to connect to each of the donors before reaching the limit.