InnoDB Cluster 集成了 MySQL Clone 插件，以提供加入实例的自动配置。检索集群数据以便实例可以与集群同步的过程称为分布式恢复。当实例需要恢复集群的事务时，我们区分提供者（提供数据的集群实例）和接收者（从提供者接收数据的实例）。在以前的版本中，组复制仅提供异步复制来恢复加入实例与集群同步所需的事务，以便它可以加入集群。对于具有大量先前处理过的事务的集群，新实例可能需要很长时间才能恢复所有事务，然后才能加入集群。或者，已清除 GTID 的集群（例如，作为定期维护的一部分）可能会缺少恢复新实例所需的一些事务。在这种情况下，唯一的选择是使用 MySQL 企业备份等工具手动配置实例，如将 MySQL 企业备份与组复制一起使用中所示。

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

克隆操作将快照传输到接收者后，如果集群在传输快照时已处理事务，则使用异步复制来恢复接收者与集群同步所需的任何数据。这比实例使用异步复制恢复所有事务要高效得多，并且可以避免清除 GTID 造成的任何问题，从而使您能够快速为 InnoDB Cluster 配置新实例。有关更多信息，请参阅克隆插件和用于分布式恢复的克隆

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

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

克隆版本兼容性检查适用于提供者和接收者实例。在某些情况下，只需要主版本号和次版本号匹配，而修订号则被忽略。

适用以下条件