【MySQL Shell】8.9 InnoDB ClusterSet 的修复和重新加入_removecluster()

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 集群和整个 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：

1. 使用 MySQL Shell， 使用 InnoDB cluster 管理员帐户（使用 cluster.setupAdminAccount() 创建）连接到主集群或副本集群中的任何成员服务器。您也可以使用 InnoDB 集群服务器配置帐户，该帐户也具有所需的权限。建立连接后，使用 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>
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12

2. 在 MySQLShell 中使用 AdminAPI 的 clusterSet.status() 命令检查整个部署的状态。使用 extended 选项查看问题的确切位置和内容。例如：

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

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

3. 仍然使用 InnoDB Cluster 管理员帐户（使用 cluster.setupAdminAccount() 创建）或 InnoDB Cluster 服务器配置帐户，使用 dba.getCluster() 获取 Cluster 对象。您可以连接到正在修复的集群中的任何成员服务器，也可以连接到 InnoDB ClusterSet 的任何成员，并使用 dba.getCluster() 上的 name 参数指定所需的集群。例如：

    mysql-js> cluster2 = dba.getClusterSet() 
   < Cluster:clustertwo> 
   1
   2

4. 在 MySQL Shell 中使用 AdminAPI 的 cluster.status() 命令检查集群的状态。使用 extended 选项获取有关集群的最详细信息。例如：

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

   有关输出的说明，请参阅 使用 cluster.Status() 检查集群的状态 。

5. 在发生紧急故障切换后，如果 ClusterSet 的各个部分之间存在事务集不同的风险，则必须保护集群不受写入流量或所有流量的影响。8.9.1 在 InnoDB ClusterSet 中隔离集群 解释了 MySQL Shell 8.0.28 中如何将集群隔离和解除隔离。

6. 如果集群上的事务集（ GTID 集）不一致，请首先解决此问题。如果副本集群的 GTID 集与 InnoDB ClusterSet 中主集群上的 GTID 设置不一致，clusterSet.status() 命令会执行警告。处于此状态的副本集群具有全局状态 OK_NOT_CONSISTENT 。 您还需要检查在受控切换或紧急故障切换过程中标记为无效的前主集群或副本集群上的 GTID 集。 与 ClusterSet 中的其他集群相比，具有额外事务的集群可以在保持活动状态的同时继续在 ClusterSet 中正常运行。但是，具有额外事务的集群无法重新加入 ClusterSet。8.9.2 InnoDB ClusterSet 集群中的不一致事务集（GTID集） 解释了如何检查和解决服务器上的事务问题。

7. 如果集群中的成员服务器或集群的总体成员身份存在技术问题（例如容错能力不足或丢失法定人数），您可以使用单个成员服务器或调整集群成员身份来解决此问题。8.9.3 修复 InnoDB ClusterSet 中的成员服务器和集群 解释了可用于集群中成员服务器的操作。

8. 如果无法修复集群，可以使用 clusterSet.removeCluster() 命令将其从 InnoDB ClusterSet 中删除。有关执行此操作的说明，请参阅 8.9.4 从 InnoDB ClusterSet 中移除集群 。无法将删除的 InnoDB Cluster 添加回 InnoDB ClusterSet 部署中。如果要再次在部署中使用这些服务器实例，则需要使用它们设置新的集群。

9. 当您修复了集群或执行了所需的维护时，可以使用 clusterSet.rejoin() 命令将其重新加入到 InnoDB ClusterSet。 此命令验证集群是否能够重新加入、更新和启动 ClusterSet 复制通道，并从集群中删除任何无效状态。有关此操作的说明，请参阅 8.9.5 将集群重新加入到 InnoDB ClusterSet 。