InnoDB 集群集成了 MySQL Clone 插件，以提供加入实例的自动配置。获取集群数据以使实例能够与集群同步的过程称为分布式恢复。当实例需要恢复集群的事务时，我们区分 捐赠者，它是提供数据的集群实例，以及 接收者，它是接收捐赠者数据的实例。在以前的版本中，组复制仅提供异步复制以恢复加入实例与集群同步所需的交易，以便它可以加入集群。对于具有大量先前处理过的交易的集群，新实例可能需要很长时间才能恢复所有交易才能加入集群。或者，已清除 GTID 的集群（例如，作为定期维护的一部分）可能会丢失恢复新实例所需的一些交易。在这种情况下，唯一的替代方法是使用 MySQL Enterprise Backup 等工具手动配置实例，如 在组复制中使用 MySQL Enterprise Backup 所示。

MySQL Clone 为实例恢复与集群同步所需的交易提供了一种替代方法。MySQL Clone 不依赖异步复制来恢复交易，而是对捐赠者实例上的数据进行快照，然后将快照传输到接收者。

克隆操作将快照传输到接收者后，如果集群在传输快照期间处理了交易，则使用异步复制来恢复接收者与集群同步所需的任何数据。这比实例使用异步复制恢复所有交易效率高得多，并且避免了因清除 GTID 导致的任何问题，使您能够快速配置 InnoDB 集群的新实例。有关更多信息，请参阅 克隆插件 和 用于分布式恢复的克隆

与使用 MySQL Clone 相反，增量恢复是实例加入集群时仅使用异步复制从集群恢复实例的过程。当 InnoDB 集群配置为使用 MySQL Clone 时，加入集群的实例使用 MySQL Clone 或增量恢复来恢复集群的事务。默认情况下，集群会自动选择最合适的方法，但您也可以选择配置此行为，例如强制克隆，这将替换加入实例已处理的任何交易。当您在交互模式下使用 MySQL Shell 时，默认情况下，如果集群不确定它是否可以继续进行恢复，它将提供一个交互式提示。本节描述为您提供的不同选项，以及影响您可选择哪些选项的不同场景。

此外，Cluster.status() 的输出，对于 RECOVERING 状态下的成员，包括恢复进度信息，使您能够轻松监控恢复操作，无论它们是使用 MySQL Clone 还是增量恢复。InnoDB 集群在 Cluster.status() 的输出中提供了有关使用 MySQL Clone 的实例的更多信息。

克隆版本兼容性检查适用于捐赠者和接收者实例。在某些情况下，仅主要版本号和次要版本号需要匹配，修补程序号将被忽略。

以下条件适用