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 [email protected]:4410
Creating a session to '[email protected]:4410'
Please provide the password for '[email protected]:4410': ********
Save password for '[email protected]: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:[email protected]: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”。