InnoDB Cluster 整合了 MySQL Clone 外掛程式，以提供加入執行個體的自動佈建。擷取叢集資料以使執行個體可以與叢集同步的程序稱為分散式復原。當執行個體需要復原叢集的交易時，我們會區分 提供者（即提供資料的叢集執行個體）和 接收者（即從提供者接收資料的執行個體）。在先前的版本中，群組複寫僅提供非同步複寫來復原加入執行個體與叢集同步所需的交易，以便其可以加入叢集。對於具有大量先前處理過的交易的叢集，新的執行個體可能需要很長時間才能復原所有交易，然後才能加入叢集。或者，例如，作為定期維護的一部分而清除了 GTID 的叢集可能缺少復原新執行個體所需的一些交易。在這種情況下，唯一的替代方法是使用 MySQL Enterprise Backup 等工具手動佈建執行個體，如搭配群組複寫使用 MySQL Enterprise Backup中所示。

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 的執行個體的其他資訊。

存在針對提供者和接收者執行個體的複製版本相容性檢查。在特定條件下，只需要符合主要和次要版本號碼，會忽略修補程式號碼。

適用下列條件