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

版本 8.4

9.0
8.0

MySQL Shell 8.4 / 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 Cluster

使用 MySQL Shell，使用 InnoDB Cluster 管理員帳戶 (使用 cluster.setupAdminAccount() 建立) 連線到主要叢集或其中一個複本叢集中的任何成員伺服器。您也可以使用 InnoDB Cluster 伺服器組態帳戶，該帳戶也具有所需的權限。建立連線後，使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令取得 ClusterSet 物件。務必使用 InnoDB Cluster 管理員帳戶或伺服器組態帳戶，以便儲存在 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 管理員帳戶 (使用 cluster.setupAdminAccount() 建立) 或 InnoDB Cluster 伺服器組態帳戶，使用 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 Cluster 無法新增回 InnoDB ClusterSet 部署。如果您想再次使用部署中的伺服器執行個體，您需要使用它們設定新的叢集。
當您修復叢集或執行所需的維護時，可以使用 clusterSet.rejoin() 命令將其重新加入 InnoDB ClusterSet。此命令會驗證叢集是否能夠重新加入、更新並啟動 ClusterSet 複寫通道，並從叢集中移除任何無效的狀態。如需執行此操作的說明，請參閱第 8.9.5 節，「將叢集重新加入 InnoDB ClusterSet」。