PDF (美式信紙) - 2.2Mb
PDF (A4) - 2.3Mb
使用 MySQL Clone 的 InnoDB 叢集提供下列額外行為。
依預設，當在 MySQL Clone 外掛程式可用的執行個體上建立新的叢集時，會自動安裝並將叢集設定為支援複製。會使用所需的 BACKUP_ADMIN 權限建立 InnoDB 叢集復原帳戶。
將 disableClone 布林選項設定為 true，以停用叢集的 MySQL Clone。在這種情況下，會為此組態新增中繼資料項目，如果已安裝，則會解除安裝 MySQL Clone 外掛程式。您可以在發出 dba.createCluster() 時設定 disableClone 選項，或在叢集使用 Cluster.setOption()
如果新的執行個體執行 MySQL 8.0.17 或更新版本，而且叢集中至少有一個捐贈者 (包含在 group_replication_group_seeds 清單中) 執行 MySQL 8.0.17 或更新版本，則可將 MySQL Clone 用於加入的 instance。使用 MySQL Clone 的叢集遵循 第 7.4.4 節「將執行個體新增至 InnoDB 叢集」 中記載的行為，並額外選擇如何傳輸從叢集復原執行個體所需的資料。Cluster.addInstance(instance)
是否支援 MySQL Clone。
是否有可能進行增量復原，這取決於二進位日誌的可用性。例如，如果捐贈者執行個體具有所有需要的二進位日誌 (
GTID_PURGED為空)，則有可能進行增量復原。如果沒有叢集執行個體具有所有需要的二進位日誌，則無法進行增量復原。-
增量復原是否適當。即使有可能進行增量復原，由於它可能會與執行個體上已有的資料衝突，因此會檢查捐贈者和接收者的 GTID 集，以確保增量復原適當。下列是比較的可能結果
新的：接收者具有空的
GTID_EXECUTEDGTID 集相同：接收者具有與捐贈者 GTID 集相同的 GTID 集
可復原：接收者具有遺失交易的 GTID 集，但這些交易可以從捐贈者復原
無法復原：捐贈者具有遺失交易的 GTID 集，可能已清除這些交易
已發散：捐贈者和接收者的 GTID 集已發散
當判斷比較的結果為相同或可復原時，會認為增量復原適當。當判斷比較的結果為無法復原或已發散時，會認為增量復原不適當。
對於被視為新的執行個體，無法認為增量復原適當，因為不可能判斷二進位日誌是否已清除，甚至是
GTID_PURGED和GTID_EXECUTED變數是否已重設。或者，可能是伺服器在啟用二進位日誌和 GTID 之前已處理交易。因此，在互動模式中，您必須確認要使用增量復原。 -
gtidSetIsComplete選項的狀態。如果您確定叢集已使用完整的 GTID 集建立，因此可以在沒有額外確認的情況下將具有空的 GTID 集的執行個體新增至其中，請將叢集層級的gtidSetIsComplete布林選項設定為true。警告將
gtidSetIsComplete選項設定為true表示不論加入的伺服器包含任何資料，都會復原這些伺服器，請謹慎使用。如果您嘗試新增已套用交易的執行個體，您可能會面臨資料損毀的風險。
當您發出 Cluster.addInstance()recoveryMethod 選項會設定為 auto，這表示在 MySQL Shell 的互動模式中，叢集會選取從叢集復原執行個體的最佳方式，並且提示會建議您如何進行。換句話說，叢集會根據最佳方法和伺服器支援的項目，建議使用 MySQL Clone 或增量復原。如果您未使用互動模式，而是撰寫 MySQL Shell 指令碼，則必須將 recoveryMethod 設定為您要使用的復原類型 - clone 或 incremental。本節說明不同的可能案例。
當您在互動模式中使用 MySQL Shell 時，包含新增執行個體所有可能選項的主要提示是
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):根據上述因素，您可能不會獲得所有這些選項。本節稍後描述的案例會說明提供給您的選項。此提示提供的選項為
複製：選擇此選項可將捐贈者複製到您要新增至叢集的執行個體，並刪除執行個體包含的任何交易。會自動安裝 MySQL Clone 外掛程式。會使用所需的
BACKUP_ADMIN權限建立 InnoDB 叢集復原帳戶。假設您新增的執行個體是空的 (尚未處理任何交易)，或是包含您不想保留的交易，請選取複製選項。然後，叢集會使用 MySQL Clone，以捐贈者叢集成員的快照完整覆寫加入的執行個體。若要依預設使用此方法並停用此提示，請將叢集的recoveryMethod選項設定為clone。增量復原 選擇此選項可使用增量復原，透過非同步複寫將叢集處理的所有交易復原到加入的執行個體。如果您確定叢集處理的所有更新都是在啟用 GTID 的情況下完成，且沒有已清除的交易，而且新的執行個體包含與叢集相同的 GTID 集或其子集，則增量復原很適合。若要依預設使用此方法，請將
recoveryMethod選項設定為incremental。
上述因素的組合會影響提示中可用的選項，如下所示
注意
如果已在 AdminAPI 之外手動變更 group_replication_clone_threshold 系統變數，則叢集可能會決定使用複製復原，而不是遵循這些案例。
-
在下列案例中
可能進行增量復原
增量復原不適當
支援複製
您可以在任何選項之間選擇。建議您使用預設的 MySQL Clone。
-
在下列案例中
可能進行增量復原
增量復原適當
系統不會提供提示，並使用增量復原。
-
在下列案例中
可能進行增量復原
增量復原不適當
不支援或停用複製
您無法使用 MySQL Clone 將執行個體新增至叢集。系統會提供提示，且建議的選項是繼續進行增量復原。
-
在下列案例中
無法進行增量復原
不支援或停用複製
您無法將執行個體加入叢集，並且會顯示 錯誤：目標執行個體在加入目標叢集之前，必須先經過複製或完整佈建。Cluster.addInstance：需要佈建執行個體 (RuntimeError)。這可能是由於所有叢集執行個體中的二進位日誌已清除所導致。建議使用 MySQL Clone，可以透過升級叢集或將
disableClone選項設定為false來達成。 -
在下列案例中
無法進行增量復原
支援複製
您只能使用 MySQL Clone 將執行個體加入叢集。這可能是由於叢集遺失二進位日誌所導致，例如當它們已被清除時。
當您從提示中選擇一個選項後，預設情況下會顯示執行個體從叢集恢復交易的進度。此監控功能可讓您檢查恢復階段是否正常運作，以及執行個體加入叢集並上線所需的時間。要取消監控恢復階段，請按下 CONTROL+C。