MySQL :: MySQL Shell 9.0 :: 8.9 InnoDB ClusterSet 修復與重新加入

版本 9.0

8.4 目前
8.0

MySQL Shell 9.0 / MySQL InnoDB ClusterSet / InnoDB ClusterSet 修復與重新加入

8.9 InnoDB ClusterSet 修復與重新加入

8.9.1 在 InnoDB ClusterSet 中隔離叢集
8.9.2 InnoDB ClusterSet 叢集中不一致的交易集 (GTID 集)
8.9.3 修復 InnoDB ClusterSet 中的成員伺服器與叢集
8.9.4 從 InnoDB ClusterSet 移除叢集
8.9.5 將叢集重新加入 InnoDB ClusterSet

如果您需要在 InnoDB ClusterSet 部署中修復叢集，請使用此資訊。您可以在下列任何情況下使用此處的資訊

InnoDB ClusterSet 中的叢集需要維護，但其功能沒有問題。
叢集在 InnoDB ClusterSet 部署中運作良好，但有一些問題，例如成員伺服器離線。
叢集無法正常運作，需要修復。
叢集在緊急容錯移轉或受控切換程序中被標記為無效。

第 8.6 節，「InnoDB ClusterSet 狀態與拓撲」說明如何檢查 InnoDB Cluster 以及整個 InnoDB ClusterSet 部署的狀態，以及叢集可能需要修復的情況。您可以從 clusterSet.status() 命令的輸出中識別以下情況

叢集沒有仲裁 (也就是說，沒有足夠的成員在線上以取得多數)。
無法連線到叢集的任何成員。
叢集的 ClusterSet 複寫通道已停止。
叢集的 ClusterSet 複寫通道設定不正確。
叢集的 GTID 集與 InnoDB ClusterSet 中主要叢集的 GTID 集不一致。
叢集已被標記為無效。如果叢集仍處於線上狀態，則命令會警告可能會導致腦裂情況。

如果叢集是 InnoDB ClusterSet 部署中的主要叢集，在修復它之前，您可能需要執行受控切換或緊急容錯移轉，將其降級為複本叢集。之後，您可以根據需要將叢集離線以進行修復，而 InnoDB ClusterSet 在此期間將保持可用。

如果主要叢集運作良好但需要維護或有一些小問題，則適用受控切換。當您使用 clusterSet.status() 命令檢查時，運作良好的主要叢集具有全域狀態 OK。第 8.7 節，「InnoDB ClusterSet 受控切換」說明如何執行此操作。
如果您完全無法連線到主要叢集，則適用緊急容錯移轉。第 8.8 節，「InnoDB ClusterSet 緊急容錯移轉」說明如何執行此操作。
如果主要叢集無法正常運作 (全域狀態為 NOT_OK)，但可以連線，請嘗試使用本節中的資訊修復任何問題。緊急容錯移轉存在遺失交易和為 InnoDB ClusterSet 建立腦裂情況的風險。如果您無法快速修復主要叢集以恢復可用性，請繼續進行緊急容錯移轉，然後在可能的情況下進行修復。

請按照此程序修復屬於 InnoDB ClusterSet 部署一部分的 InnoDB 叢集

使用 MySQL Shell，透過 InnoDB 叢集管理員帳戶 (使用 cluster.setupAdminAccount() 建立) 連線到主要叢集或其中一個複本叢集中的任何成員伺服器。您也可以使用 InnoDB 叢集伺服器設定帳戶，該帳戶也具有所需的權限。建立連線後，使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令取得 ClusterSet 物件。務必使用 InnoDB 叢集管理員帳戶或伺服器設定帳戶，以便儲存在 ClusterSet 物件中的預設使用者帳戶具有正確的權限。例如

mysql-js> \connect admin2@127.0.0.1:4410
Creating a session to 'admin2@127.0.0.1:4410'
Please provide the password for 'admin2@127.0.0.1:4410': ********
Save password for 'admin2@127.0.0.1:4410'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Closing old connection...
Your MySQL connection id is 42
Server version: 8.0.27-commercial MySQL Enterprise Server - Commercial
No default schema selected; type \use <schema> to set one.
<ClassicSession:admin2@127.0.0.1:4410>
mysql-js> myclusterset = dba.getClusterSet()
<ClusterSet:testclusterset>

在 MySQL Shell 中使用 AdminAPI 的 clusterSet.status() 命令檢查整個部署的狀態。使用 extended 選項，以確切查看問題所在及問題是什麼。例如
```
mysql-js> myclusterset.status({extended: 1})
```
如需輸出的說明，請參閱第 8.6 節，「InnoDB ClusterSet 狀態與拓撲」。
仍然使用 InnoDB 叢集管理員帳戶 (使用 cluster.setupAdminAccount() 建立) 或 InnoDB 叢集伺服器設定帳戶，使用 dba.getCluster() 取得 Cluster 物件。您可以連線到您要修復的叢集中的任何成員伺服器，或連線到 InnoDB ClusterSet 的任何成員，並在 dba.getCluster() 上使用 name 參數來指定您要的叢集。例如
```
mysql-js> cluster2 = dba.getClusterSet()
<Cluster:clustertwo>
```
在 MySQL Shell 中使用 AdminAPI 的 cluster.status() 命令檢查叢集的狀態。使用 extended 選項以取得有關叢集的最詳細資訊。例如
```
mysql-js> cluster2.status({extended: 2})
```
如需輸出的說明，請參閱使用 Cluster.status() 檢查叢集的狀態。
在緊急容錯移轉之後，如果 ClusterSet 各部分之間的交易集存在差異的風險，您必須將叢集隔離，使其無法接收寫入流量或所有流量。第 8.9.1 節，「在 InnoDB ClusterSet 中隔離叢集」說明如何從 MySQL Shell 8.0.28 開始隔離和取消隔離叢集。
如果叢集上的交易集 (GTID 集) 不一致，請先修正此問題。如果複本叢集的 GTID 集與 InnoDB ClusterSet 中主要叢集的 GTID 集不一致，則 clusterSet.status() 命令會發出警告。處於此狀態的複本叢集具有全域狀態 OK_NOT_CONSISTENT。您也需要檢查先前的主要叢集或複本叢集上的 GTID 集，這些叢集在受控切換或緊急容錯移轉程序中被標記為無效。與 ClusterSet 中其他叢集相比，具有額外交易的叢集可以在保持活動狀態時繼續在 ClusterSet 中正常運作。但是，具有額外交易的叢集無法重新加入 ClusterSet。第 8.9.2 節，「InnoDB ClusterSet 叢集中不一致的交易集 (GTID 集)」說明如何檢查和解決伺服器上交易的問題。
如果叢集中的成員伺服器或叢集的整體成員資格 (例如容錯不足或仲裁遺失) 存在技術問題，您可以處理個別的成員伺服器或調整叢集成員資格來解決此問題。第 8.9.3 節，「修復 InnoDB ClusterSet 中的成員伺服器與叢集」說明有哪些可用操作可處理叢集中的成員伺服器。
如果您無法修復叢集，可以使用 clusterSet.removeCluster() 命令從 InnoDB ClusterSet 中移除它。如需執行此操作的指示，請參閱第 8.9.4 節，「從 InnoDB ClusterSet 移除叢集」。移除的 InnoDB 叢集無法新增回 InnoDB ClusterSet 部署中。如果您想再次使用部署中的伺服器實例，則需要使用它們設定新的叢集。
當您修復叢集或執行所需的維護後，可以使用 clusterSet.rejoin() 命令將其重新加入 InnoDB ClusterSet。此命令會驗證叢集是否能夠重新加入、更新並啟動 ClusterSet 複寫通道，並從叢集中移除任何無效狀態。如需執行此操作的指示，請參閱第 8.9.5 節，「將叢集重新加入 InnoDB ClusterSet」。