Documentation Home
MySQL 外壳 8.0
MySQL 外壳 8.0  / 第 8 章 MySQL InnoDB ClusterSet  /  8.9 InnoDB ClusterSet修复和重新加入

8.9 InnoDB ClusterSet修复和重新加入

8.9.1 InnoDB ClusterSet 中的 Fencing 集群
8.9.2 InnoDB ClusterSet 集群中的不一致事务集（GTID 集）
8.9.3 修复InnoDB ClusterSet中的成员服务器和集群
8.9.4 从 InnoDB ClusterSet 中删除一个 Cluster
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 在此期间将保持可用。

  • 如果主集群运行正常但需要维护或存在小问题，则可控切换是合适的。OK当您使用 clusterSet.status() 命令检查时，运行正常的主集群具有全局状态。第 8.7 节，“InnoDB ClusterSet 控制切换” 解释了如何执行此操作。

  • 如果您根本无法联系主集群，则适合紧急故障转移。 第 8.8 节，“InnoDB ClusterSet 紧急故障转移”解释了如何执行此操作。

  • 如果主集群运行不正常（具有全局状态NOT_OK）但可以联系到它，请尝试使用本节中的信息修复任何问题。紧急故障转移会带来丢失事务和为 InnoDB ClusterSet 造成脑裂情况的风险。如果您无法快速修复主集群以恢复可用性，请继续进行紧急故障转移，然后在可能的情况下进行修复。

按照此过程修复作为 InnoDB ClusterSet 部署一部分的 InnoDB Cluster：

  1. 使用 MySQL Shell，使用 InnoDB Cluster 管理员帐户（使用创建 cluster.setupAdminAccount()）连接到主集群或其中一个副本集群中的任何成员服务器。您还可以使用 InnoDB Cluster 服务器配置帐户，该帐户也具有所需的权限。建立连接后， ClusterSet使用 dba.getClusterSet()or cluster.getClusterSet() 命令获取对象。使用 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>

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

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

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

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

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

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

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

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

  5. 在 紧急故障转移之后，并且存在事务集在 ClusterSet 的各个部分之间不同的风险，您必须隔离集群以防止写入流量或所有流量。 第 8.9.1 节，“InnoDB ClusterSet 中的防护集群”解释了如何从 MySQL Shell 8.0.28 防护和取消防护集群。

  6. 如果集群上的事务集（GTID 集）不一致，请先解决这个问题。clusterSet.status() 如果副本集群的 GTID 集与 InnoDB ClusterSet 中主集群上设置的 GTID 不一致，该 命令会发出警告。处于此状态的副本集群具有全局状态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”。