In MySQL 8.0.17, InnoDB cluster integrates the MySQL Clone plugin to provide automatic provisioning of joining instances. In previous versions, Group Replication provided only asynchronous replication to transfer the transactions required for the joining instance to synchronize with the cluster so that it could join the cluster. For a cluster with a large amount of previously processed transactions it could take a long time for the new instance to apply all of the transactions before being able to join the cluster. Or a cluster which had purged GTIDs, for example as part of regular maintenance, could be missing some of the transactions required to synchronize the new instance. In such cases the only alternative was to manually provision the instance using tools such as MySQL Enterprise Backup, as shown in Section 18.4.6, “Using MySQL Enterprise Backup with Group Replication”.

The process of retrieving the cluster's data so that the instance can synchronize with the cluster is called recovery. When an instance needs to recover a cluster's transactions we distinguish between the donor, which is the cluster instance that provides the data to the cloned instance, and the receiver, which is the instance that receives the cloned data from the donor. MySQL Clone provides an alternative way for an instance to recover the transactions required to synchronize with a cluster. Instead of relying on asynchronous replication to transfer the data, MySQL Clone takes a snapshot of the data on the donor instance and then transfers the snapshot to the receiver.

Once a clone operation has transferred the snapshot to the receiver, if the cluster has processed transactions while the snapshot was being transferred, asynchronous replication is used to transfer any required data for the receiver to be synchronized with the cluster. This can be much more efficient than the instance applying all of the transactions using asynchronous replication, and avoids any issues caused by purged GTIDs, enabling you to quickly provision new instances for InnoDB cluster. For more information, see Section 5.6.7, “The Clone Plugin” and Section 18.4.3.1, “Cloning for Distributed Recovery”

In contrast to using MySQL Clone, incremental recovery is the process where an instance joining a cluster uses only asynchronous replication to synchronize with the cluster. When an InnoDB cluster is configured to use MySQL Clone, instances which join the cluster use either MySQL Clone or incremental recovery to recover the cluster's transactions. By default, the cluster automatically chooses the most suitable method, but you can optionally configure this behavior, for example to force cloning, which replaces any transactions already processed by the joining instance. When you are using MySQL Shell in interactive mode, the default, if the cluster is not sure it can proceed with recovery it provides an interactive prompt. This section describes the different options you are offered, and the different scenarios which influence which of the options you can choose.

In addition, the output of Cluster.status() for members in RECOVERING state includes recovery progress information to enable you to easily monitor recovery operations, whether they are using MySQL Clone or incremental recovery . InnoDB cluster provides additional information about instances using MySQL Clone in the output of Cluster.status().