使用 MySQL Shell，连接到 InnoDB ClusterSet 部署中仍处于活动状态的任何成员服务器，使用 InnoDB Cluster 管理员帐户（使用创建 cluster.setupAdminAccount()）。您还可以使用 InnoDB Cluster 服务器配置帐户，该帐户也具有所需的权限。

建立连接 ClusterSet后，使用dba.getClusterSet()or 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 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>

clusterSet.status() 使用MySQL Shell 中 的 AdminAPI 函数检查整个部署的状态 。使用该extended 选项可以准确查看问题出在哪里和出什么问题。例如：

mysql-js> myclusterset.status({extended: 1})

有关输出的解释，请参阅 第 8.6 节，“InnoDB ClusterSet 状态和拓扑”。

InnoDB Cluster 可以容忍一些问题并且运行良好以继续作为 InnoDB ClusterSet 部署的一部分。OK当您使用 clusterSet.status() 命令检查时，运行正常的主集群具有全局状态 。例如，如果集群中的一个成员服务器脱机，即使该服务器是主服务器，底层的 Group Replication 技术也可以处理这种情况并重新配置自身。

如果根据报告的状态，主集群在 InnoDB ClusterSet 部署中仍然可以正常运行，但您需要进行维护或修复一些小问题以提高主集群的功能，您可以进行受控切换到副本集群。然后，如有必要，您可以使主集群脱机，修复任何问题，并在 InnoDB ClusterSet 部署中将其恢复运行。有关执行此操作的说明，请参阅 第 8.7 节，“InnoDB ClusterSet 控制切换”。

如果主集群NOT_OK在 InnoDB ClusterSet 部署中无法正常运行（具有全局状态），但您可以联系它，请首先尝试通过 MySQL Shell 使用 AdminAPI 修复任何问题。例如，如果主集群丢失了仲裁，则可以使用 cluster.forceQuorumUsingPartitionOf 命令将其恢复。有关执行此操作的说明，请参阅 第 8.9 节，“InnoDB ClusterSet 修复和重新加入”。

如果您无法执行受控切换，并且无法通过使用主集群来足够快地解决问题（例如，因为您无法联系它），请继续进行紧急故障转移。首先确定一个合适的副本集群，可以接管为主集群。副本集群是否有资格进行紧急故障转移取决于其全局状态，如以下 clusterSet.status() 命令所报告：

您选择的副本集群必须在所有可访问的副本集群中具有最新的事务集（GTID 集）。如果多个副本集群符合紧急故障转移的条件，请检查每个集群的复制滞后（显示在 clusterSet.status() 命令的扩展输出中）。选择复制滞后最少的副本集群，因此它应该有最多的事务。紧急故障转移过程检查当前可访问的所有副本集群的 GTID 集，并告诉您另一个集群是否更新，以便您可以再次尝试使用该集群。

clusterSet.routingOptions() 通过在连接到 InnoDB ClusterSet 部署中的任何成员服务器时在 MySQL Shell 中 发出命令，检查为每个 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 实例显示路由选项，如上例中的"target_cluster"for Rome2，则意味着该实例没有设置该策略，它遵循全局策略。

如果任何实例设置为按名称 ( ) 定位当前主集群，它们将不会将流量重定向到新的主集群。当主集群不工作时，该 命令不能用于更改路由选项，因此在故障转移到新的主集群完成之前，您不能重定向由该 MySQL Router 实例处理的流量。 "target_cluster": "name_of_primary_cluster"clusterSet.setRoutingOption()

如果可以，请尝试验证原始主集群是否处于离线状态，如果在线，请尝试将其关闭。如果它保持在线并继续接收来自客户端的流量，则可能会在 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 实例现在是否正确路由。

使用该选项再次发出 clusterSet.status() 命令extended，以验证 InnoDB ClusterSet 部署的状态。

如果您能够再次联系到旧的主集群，请首先确保没有应用程序流量路由到它，然后将其脱机。然后按照 第 8.9 节“InnoDB ClusterSet 修复和重新加入”中的过程检查事务并决定如何安排 InnoDB ClusterSet 拓扑。

在紧急故障转移之后，存在事务集在 ClusterSet 的各个部分之间不同的风险，您必须隔离集群以防止写入流量或所有流量。有关更多详细信息，请参阅 InnoDB ClusterSet 中的防护集群。

如果在切换过程中必须使任何副本集群无效，并且当您能够再次联系它们时，您可以使用 第 8.9 节“InnoDB ClusterSet 修复和重新加入”中的过程来修复它们并将它们添加回 InnoDB集群集。