Distributed Recovery 18.5.3 Distributed Recovery Tip 3736 State transfer from the binary log is Group Replication’s base mechanism for distributed recovery  and if the donors and joining members in your replication When the joining member is up to date with all the group’s transactions  it is declared online and can participate in the group as a normal member  and distributed recovery is complete. Group Replication automatically selects the best combination of these methods for state transfer after you issue  START GROUP_REPLICATION  on the joining member. To do this  Group Replication checks which existing members are suitable as donors  how many transactions the joining member needs from a donor  and whether any required transactions are no longer present in the binary log files on any group member. If the transaction gap between the joining member and a suitable donor is large  or if some required transactions are not in any donor’s binary log files  Group Replication begins distributed recovery with a remote cloning operation. If there is not a large transaction gap  or if the clone plugin is not installed  Group Replication proceeds directly to state transfer from a donor’s binary log. Group Replication uses a combination of these methods for state transfer during distributed recovery: After this  the joining member connects to an online existing member to carry out state transfer. The joining member transfers all the transactions that took place in the group before it joined or while it was away  which are provided by the existing member (called the  donor ). Next  the joining member applies the transactions that took place in the group while this state transfer was in progress. When this process is complete  the joining member has caught up with the remaining servers in the group  and it begins to participate normally in the group. The joining member begins by checking the relay log for its  group_replication_applier  channel for any transactions that it already received from the group but did not yet apply. If the joining member was in the group previously  it might find unapplied transactions from before it left  in which case it applies these as a first step. A member that is new to the group does not have anything to apply. Whenever a member joins or rejoins a replication group  it must catch up with the transactions that were applied by the group members before it joined  or while it was away. This process is called distributed recovery. •A remote cloning operation using the clone plugin’s function  which is available from MySQL 8.0.17. To enable this method of state transfer  you must install the clone plugin on the group members and the joining member. Group Replication automatically configures the required clone plugin settings and manages the remote cloning operation. •Replicating from a donor’s binary log and applying the transactions on the joining member. This method uses a standard asynchronous replication channel named  group_replication_recovery  that is established between the donor and the joining member. •During a remote cloning operation  the existing data on the joining member is removed  and replaced with a copy of the donor’s data. When the remote cloning operation is complete and the joining member has restarted  state transfer from a donor’s binary log is carried out to get the transactions that the group applied while the remote cloning operation was in progress. •During state transfer from a donor’s binary log  the joining member replicates and applies the required transactions from the donor’s binary log  applying the transactions as they are received  up to the point where the binary log records that the joining member joined the group (a view change event). While this is in progress  the joining member buffers the new transactions that the group applies. When state transfer from the binary log is complete  the joining member applies the buffered transactions.