Distributed Recovery select a remote cloning operation for state transfer where this is more appropriate, set the system variable to specify a number of transactions as the transaction gap above which you want cloning to take place. Do not use a low setting for  group_replication_clone_threshold  in an active group. If a number of transactions above the threshold takes place in the group while the remote cloning operation is in progress, the joining member triggers a remote cloning operation again after restarting, and could continue this indefinitely. To avoid this situation, ensure that you set the threshold to a number higher than the number of transactions that you would expect to occur in the group during the time taken for the remote cloning operation. Group Replication attempts to execute a remote cloning operation regardless of your threshold when state transfer from a donor’s binary log is impossible, for example because the transactions needed by the joining member are not available in the binary log on any existing group member. Group Replication identifies this based on the  gtid_purged  sets of the existing group members. You cannot use the group_replication_clone_threshold  system variable to deactivate cloning when the required transactions are not available in any member’s binary log files, because in that situation cloning is the only alternative to transferring data to the joining member manually. When group members and joining members are set up for cloning, Group Replication manages remote cloning operations for you. A remote cloning operation might take some time to complete, depending on the size of the data. See Section 5.6.7.9, “Monitoring Cloning Operations”  for information on monitoring the process. When state transfer is complete, Group Replication restarts the joining member to complete the process. If  group_replication_start_on_boot=OFF  is set on the joining member, for example because you specify the replication user credentials on the  START GROUP_REPLICATION  statement, you must issue  START GROUP_REPLICATION  manually again following this restart. If group_replication_start_on_boot=ON  and other settings required to start Group Replication were set in a configuration file or using a  SET PERSIST statement, you do not need to intervene and the process continues automatically to bring the joining member online. If the remote cloning procedure takes a long time, in releases before MySQL 8.0.22, it is possible for the set of certification information that accumulates for the group during that time to become too large to transmit to the joining member. In that case, the joining member logs an error message and does not join the group. From MySQL 8.0.22, Group Replication manages the garbage collection process for applied transactions differently to avoid this scenario. In earlier releases, if you do see this error, after the remote cloning operation completes, wait two minutes to allow a round of garbage collection to take place to reduce the size of the group’s certification information. Then issue the following statement on the joining member, so that it stops trying to apply the previous set of certification information: A remote cloning operation clones settings that are persisted in tables from the donor to the recipient, as well as the data. Group Replication manages the settings that relate specifically to Group Replication channels. Group Replication member settings that are persisted in configuration files, such as the group replication local address, are not cloned and are not changed on the joining member. Group Replication 3742 RESET SLAVE FOR CHANNEL group_replication_recovery; Or from MySQL 8.0.22: RESET REPLICA FOR CHANNEL group_replication_recovery; Warning Cloning Operations Note