使用 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>

使用 AdminAPI 的 clusterSet.status() 函数在 MySQL Shell 中检查整个部署的状态。使用 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 路由器实例设置的路由选项以及 InnoDB ClusterSet 部署的全局策略。例如

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

如果所有 MySQL 路由器实例都设置为跟踪主集群（"target_cluster": "primary"），则流量将在故障转移后几秒钟内自动重定向到新的主集群。如果未为 MySQL 路由器实例显示路由选项，如上面的示例中 Rome2 的 "target_cluster"，则表示该实例未设置该策略，并且遵循全局策略。

如果任何实例设置为通过名称（"target_cluster": "name_of_primary_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": "name_of_new_primary_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。