PDF (美式信紙) - 2.2Mb
PDF (A4) - 2.3Mb
如果您的叢集發生完全故障，您可以使用 dba.rebootClusterFromCompleteOutage() 重新配置它。此操作讓您可以連線到其中一個叢集的 MySQL 執行個體，並使用其元資料來還原叢集。
完全故障表示群組複寫已停止所有成員執行個體。
注意
請確保在執行 dba.rebootClusterFromCompleteOutage() 之前已啟動所有叢集成員。如果任何叢集成員無法連線，則命令將會失敗。
如果叢集已失效且是 ClusterSet 的成員，則會忽略此檢查。
連線到最新執行個體並執行下列命令
JS> var cluster = dba.rebootClusterFromCompleteOutage()如果所有成員都具有相同的 GTID 集，則您目前連線的成員會成為主要成員。請參閱使用 rebootClusterFromCompleteOutage 選取主要成員。
dba.rebootClusterFromCompleteOutage() 操作會遵循下列步驟來確保叢集已正確重新配置
叢集元資料和叢集拓撲會從目前執行個體擷取。
如果叢集成員處於 RECOVERING 或 ERROR 狀態，且所有其他成員都處於 OFFLINE 或 ERROR 狀態，則
dba.rebootClusterFromCompleteOutage()會嘗試停止該成員上的群組複寫。如果群組複寫無法停止，則命令會停止並顯示錯誤。-
會檢查 MySQL Shell 目前連線到的執行個體上找到的 InnoDB 叢集元資料，以查看它是否包含 GTID 超集。如果目前連線的執行個體未包含 GTID 超集，則操作會中止並提供該資訊。
請參閱GTID 超集。
如果執行個體包含 GTID 超集，則會根據儲存在該執行個體中的元資料還原叢集。
-
MySQL Shell 會檢查叢集中哪些執行個體目前可連線，如果任何成員目前無法連線，則會失敗。
同樣地，MySQL Shell 會偵測目前無法連線的執行個體。如果先前成員目前無法連線，則無法將其新增至叢集或移除叢集，作為
dba.rebootClusterFromCompleteOutage()命令的一部分。如果在叢集的主要執行個體上啟用，則在單一主要模式下，會停用
super_read_only。
若要重新啟動叢集，您必須連線到具有 GTID 超集的成員，這表示在故障前已套用最多交易的執行個體。
若要判斷哪個成員具有 GTID 超集，請執行下列其中一項
-
連線到執行個體並執行
dba.rebootClusterFromCompleteOutage()，並使用dryRun: true。產生的報告會傳回類似下列的資訊：。Switching over to instance '127.0.0.1:4001' to be used as seed.這表示具有 GTID 超集的成員。
對 GTID 集較低的成員執行
dba.rebootClusterFromCompleteOutage()會導致錯誤。 -
依序連線到每個執行個體，並在
SQL模式中執行下列程式碼SHOW VARIABLES LIKE 'gtid_executed';套用最大 GTID 集交易的執行個體包含 GTID 超集。
注意
可以使用 force 選項執行 dba.rebootClusterFromCompleteOutage() 來覆寫此行為，並使用具有較低 GTID 集的執行個體。
這會使選取的成員成為主要成員，並捨棄未包含在選取成員的 GTID 集中的任何交易。
如果此程序失敗，且叢集元資料已嚴重損毀，您可能需要捨棄元資料並從頭開始重新建立叢集。您可以使用 dba.dropMetadataSchema() 捨棄叢集元資料。
警告
只有在無法還原叢集時，才應將 dba.dropMetadataSchema() 方法作為最後手段。它無法還原。
如果您搭配叢集使用 MySQL Router，當您捨棄元資料時，所有目前的連線都會被捨棄，且禁止新的連線。這會導致完全故障。
dba.rebootClusterFromCompleteOutage() 具有下列選項
force: true | false (預設)：如果為 true，則即使無法連線到叢集的某些成員，或選取的主要執行個體具有分歧或較低的 GTID_SET，也必須執行此操作。請參閱強制選項dryRun: true | false (預設)：執行命令的所有驗證和步驟，但不進行任何變更。完成時會顯示報告。請參閱測試 rebootClusterFromCompleteOutage。primary：執行個體定義，代表必須選取為主要成員的執行個體。請參閱使用 rebootClusterFromCompleteOutage 選取主要成員。switchCommunicationStack: mysql | xcom：叢集重新啟動後要使用的群組複寫通訊堆疊。請參閱第 7.5.9 節「配置群組複寫通訊堆疊」。ipAllowList：使用XCOM通訊堆疊時，允許連線到執行個體進行群組複寫流量的主機清單。localAddress：字串值，其中包含要使用群組複寫本機位址，而不是在使用XCOM通訊堆疊時自動產生的位址。
force 選項讓您可以忽略叢集成員的可用性，或選取成員中的 GTID 集分歧，並重新啟動叢集。
例如，重新啟動叢集 myCluster
JS> var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{force: true})在下列情況下，不允許使用 force 選項
如果叢集屬於 ClusterSet 且已失效，或主要叢集的全域狀態不是 OK。
叢集屬於 ClusterSet、是主要叢集且已失效。
無法使用 rebootClusterFromCompleteOutage 新增或重新加入執行個體。如果您使用 force 來忽略無法連線的成員並重新啟動叢集，則必須使用 cluster.rejoinInstance()
您可以使用下列其中一種方式定義叢集的主要節點
-
在
dba.rebootClusterFromCompleteOutage()命令中定義primary選項。例如，重新啟動叢集
myCluster，並將在本機電腦上，埠號為 4001 上執行的成員設定為主要節點var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001"}) 在 GTID 集合小於其他成員的叢集成員上，將
primary選項與force選項搭配使用。
您可以使用 dryRun 選項來測試變更。此選項會驗證命令及其選項，並產生結果記錄。如果建議的變更存在問題，則會擲回例外狀況。
以下範例顯示重新啟動叢集 myCluster 的預先執行，將主要節點設定為在本機上，埠號為 4001 上執行的成員，以及它傳回的日誌訊息
JS > var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001", dryRun: true})
NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
Cluster instances: '127.0.0.1:4000' (OFFLINE), '127.0.0.1:4001' (OFFLINE), '127.0.0.1:4002' (OFFLINE)
Switching over to instance '127.0.0.1:4001' to be used as seed.
dryRun finished.
rebootClusterFromCompleteOutage 會執行以下檢查，如果叢集不符合需求，則會產生警告
確認已將複本叢集強制從 ClusterSet 中移除。
確認 ClusterSet 的主要叢集可連線。
檢查叢集是否有未屬於檢視變更日誌事件 (VCLE) 的錯誤交易。請參閱分散式復原運作方式。
確認叢集的已執行交易集合（
GTID_EXECUTED）不是空的。
此命令會自動將複本叢集重新加入 ClusterSet，確保為所有叢集成員設定 ClusterSet 複寫通道。