使用 MySQL Shell，使用 InnoDB 叢集管理員帳戶（使用 cluster.setupAdminAccount() 建立）連線至 InnoDB ClusterSet 部署中仍處於活動狀態的任何成員伺服器。您也可以使用 InnoDB 叢集伺服器組態帳戶，該帳戶也具有所需的權限。

連線建立後，使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令從該成員伺服器取得 ClusterSet 物件。您先前從現在已離線的成員伺服器檢索的 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 71
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 叢集可以容忍某些問題，並且可以正常運作，以繼續作為 InnoDB ClusterSet 部署的一部分。當您使用 clusterSet.status() 命令檢查時，功能可接受的主要叢集具有全域狀態 OK。例如，如果叢集中的其中一個成員伺服器離線，即使該伺服器是主要的，基礎群組複製技術也可以處理這種情況並重新設定自身。

如果主要叢集根據報告的狀態在 InnoDB ClusterSet 部署中仍可接受地運作，但您需要執行維護或修正一些小問題以改善主要叢集的功能，則可以執行對複本叢集的受控切換。然後，您可以視需要讓主要叢集離線，修復任何問題，並將其重新投入 InnoDB ClusterSet 部署中。如需執行此操作的指示，請參閱 第 8.7 節，InnoDB ClusterSet 受控切換。

如果主要叢集在 InnoDB ClusterSet 部署中無法接受地運作（全域狀態為 NOT_OK），但您可以連線至該叢集，請先嘗試使用 MySQL Shell 透過 AdminAPI 修復任何問題。例如，如果主要叢集失去法定人數，可以使用 cluster.forceQuorumUsingPartitionOf 命令還原它。如需執行此操作的指示，請參閱 第 8.9 節，InnoDB ClusterSet 修復與重新加入。

如果您無法執行受控切換，並且無法透過使用主要叢集快速解決問題（例如，因為您無法連線至該叢集），請繼續進行緊急故障轉移。首先識別適合接管作為主要叢集的複本叢集。複本叢集是否符合緊急故障轉移的資格取決於其全域狀態，如 clusterSet.status() 命令所報告的。

您選取的複本叢集，必須在所有可連線的複本叢集中，擁有最新的一組交易 (GTID 集)。如果有多個複本叢集符合緊急容錯移轉的資格，請檢查每個叢集的複寫延遲（顯示在 clusterSet.status() 命令的擴充輸出中）。選取複寫延遲最少的複本叢集，該叢集應因此擁有最多的交易。緊急容錯移轉程序會檢查目前可連線的所有複本叢集的 GTID 集，並告知您是否有另一個叢集較為新，因此您可以嘗試使用該叢集。

藉由在連線至 InnoDB ClusterSet 部署中任何成員伺服器的 MySQL Shell 中，發出 clusterSet.routingOptions() 命令，檢查為每個 MySQL Router 執行個體設定的路由選項，以及 InnoDB ClusterSet 部署的全域策略。例如

mysql-js> myclusterset.routingOptions()
{
    "domainName": "testclusterset",
    "global": {
        "invalidated_cluster_policy": "drop_all",
        "target_cluster": "primary"
    },
    "routers": {
        "Rome1":  {
            "target_cluster": "primary"
        },
        "Rome2": {}
    }
}

如果所有 MySQL Router 執行個體都設定為追蹤主要叢集 ("target_cluster": "primary")，則在容錯移轉後的幾秒內，流量將自動重新導向至新的主要叢集。如果沒有為 MySQL Router 執行個體顯示路由選項，例如上方範例中 Rome2 的 "target_cluster"，則表示執行個體沒有設定該策略，並會追蹤全域策略。

如果任何執行個體設定為依名稱將目標設定為目前的主要叢集 ("target_cluster": "主要叢集名稱")，則它們不會將流量重新導向至新的主要叢集。當主要叢集無法運作時，無法使用 clusterSet.setRoutingOption() 命令來變更路由選項，因此您無法重新導向該 MySQL Router 執行個體處理的流量，直到完成容錯移轉至新的主要叢集為止。

如果可以，請嘗試驗證原始主要叢集是否離線，如果其在線上，請嘗試將其關閉。如果其保持在線上並持續接收來自用戶端的流量，則可能會建立腦裂狀況，導致 InnoDB ClusterSet 的分離部分出現差異。

若要繼續進行緊急容錯移轉，請發出 clusterSet.forcePrimaryCluster() 命令，並命名將接管做為新主要叢集的複本叢集。例如

mysql-js> myclusterset.forcePrimaryCluster("clustertwo")
Failing-over primary cluster of the clusterset to 'clustertwo'
* Verifying primary cluster status
None of the instances of the PRIMARY cluster 'clusterone' could be reached.
* Verifying clusterset status
** Checking cluster clustertwo
  Cluster 'clustertwo' is available
** Checking whether target cluster has the most recent GTID set
* Promoting cluster 'clustertwo'
* Updating metadata

PRIMARY cluster failed-over to 'clustertwo'. The PRIMARY instance is '127.0.0.1:4410'
Former PRIMARY cluster was INVALIDATED, transactions that were not yet replicated may be lost.

在 clusterSet.forcePrimaryCluster() 命令中

當您發出 clusterSet.forcePrimaryCluster() 命令時，MySQL Shell 會檢查目標複本叢集是否符合接管做為主要叢集的要求，如果不符合，則會傳回錯誤。

如果目標複本叢集符合要求，則 MySQL Shell 會執行下列工作

在緊急容錯移轉期間，MySQL Shell 不會嘗試將目標複本叢集與目前的主要叢集同步，也不會鎖定目前的主要叢集。如果原始的主要叢集保持在線上，則應該在可以聯絡時立即將其關閉。

如果您有任何 MySQL Router 執行個體要切換為以新的主要叢集為目標，請立即執行。您可以將它們變更為追蹤主要叢集 ("target_cluster": "primary")，或指定接管做為主要叢集的複本叢集 ("target_cluster": "新主要叢集名稱")。例如

mysql-js> myclusterset.setRoutingOption('Rome1', 'target_cluster', 'primary')
or
mysql-js> myclusterset.setRoutingOption('Rome1', 'target_cluster', 'clustertwo')
Routing option 'target_cluster' successfully updated in router 'Rome1'.

發出 clusterSet.routingOptions() 命令，以檢查所有 MySQL Router 執行個體現在是否正確路由。

再次使用 extended 選項，發出 clusterSet.status() 命令，以驗證 InnoDB ClusterSet 部署的狀態。

當您能夠再次聯絡舊的主要叢集時，首先請確保沒有應用程式流量正在路由至該叢集，並將其離線。然後依照第 8.9 節「InnoDB ClusterSet 修復和重新加入」中的程序，檢查交易並決定如何安排未來的 InnoDB ClusterSet 拓撲。

在緊急容錯移轉之後，並且 ClusterSet 的各部分之間存在交易集不同的風險，您必須將叢集隔離，使其無法寫入流量或所有流量。如需更多詳細資訊，請參閱在 InnoDB ClusterSet 中隔離叢集。

如果您在切換程序期間必須使任何複本叢集失效，當您能夠再次聯絡它們時，可以使用第 8.9 節「InnoDB ClusterSet 修復和重新加入」中的程序來修復它們，並將它們新增回 InnoDB ClusterSet。