如果您的集群遇到完全中断，您可以使用重新配置它
dba.rebootClusterFromCompleteOutage()。此操作使您能够连接到集群的一个 MySQL 实例并使用其元数据来恢复集群。
完全中断意味着组复制已在所有成员实例上停止。
确保所有集群成员在运行之前都已启动
dba.rebootClusterFromCompleteOutage()。如果无法访问任何集群成员，该命令将失败。
如果集群是 INVALIDATED 并且是 ClusterSet 的成员，则忽略此检查。
连接到最新的实例并运行以下命令：
JS> var cluster = dba.rebootClusterFromCompleteOutage()如果所有成员都设置了相同的 GTID，则您当前连接的成员将成为主要成员。请参阅 使用 rebootClusterFromCompleteOutage 选择主节点。
该dba.rebootClusterFromCompleteOutage()
操作遵循以下步骤以确保正确地重新配置集群：
从当前实例中检索集群元数据和集群拓扑。
如果集群成员处于 RECOVERING 或 ERROR 状态，而所有其他成员处于 OFFLINE 或 ERROR 状态，则
dba.rebootClusterFromCompleteOutage()尝试停止对该成员的组复制。如果组复制未能停止，该命令将停止并显示错误。-
检查在 MySQL Shell 当前连接到的实例上找到的 InnoDB Cluster 元数据，以查看它是否包含 GTID 超集。如果当前连接的实例不包含 GTID 超集，则操作会中止并显示该信息。
请参阅GTID 超集。
如果实例包含 GTID 超集，则根据存储在该实例中的元数据恢复集群。
-
MySQL Shell 检查当前可以访问集群的哪些实例，如果当前无法访问任何成员，则失败。
同样，MySQL Shell 检测当前无法访问的实例。如果当前无法访问以前的成员，则无法作为命令的一部分向集群添加或删除
dba.rebootClusterFromCompleteOutage()它们。如果在集群的主实例上启用，而在单主模式下，
super_read_only则禁用。
要重新启动集群，您必须连接到具有 GTID 超集的成员，这意味着在中断之前应用了最多事务的实例。
要确定哪个成员具有 GTID 超集，请执行以下操作之一：
-
连接到实例并
dba.rebootClusterFromCompleteOutage()使用dryRun: true. 生成的报告返回类似于以下内容的信息：。Switching over to instance '127.0.0.1:4001' to be used as seed.这表示具有 GTID 超集的成员。
dba.rebootClusterFromCompleteOutage()针对具有较低 GTID 集的成员 运行 会导致错误。 -
依次连接到每个实例并在
SQL模式下运行以下命令：SHOW VARIABLES LIKE 'gtid_executed';应用了最大GTID事务 集 的实例 包含 GTID 超集。
dba.rebootClusterFromCompleteOutage()
通过使用force选项
运行，可以覆盖此行为，并使用具有较低 GTID 集的实例
。
这使所选成员成为主要成员，并丢弃未包含在所选成员的 GTID 集中的任何事务。
如果此过程失败，并且集群元数据已严重损坏，您可能需要删除元数据并从头开始重新创建集群。您可以使用删除集群元数据
dba.dropMetadataSchema()。
当dba.dropMetadataSchema()无法恢复群集时，只能将此方法用作最后的手段。它无法撤消。
如果您在集群中使用 MySQL Router，当您删除元数据时，所有当前连接都将被删除并禁止新连接。这会导致完全中断。
dba.rebootClusterFromCompleteOutage()有以下选项：
force: true | false (default)：如果为真，则即使无法访问集群的某些成员，或者所选的主实例具有发散或较低的 GTID_SET，也必须执行该操作。请参见 强制选项dryRun: true | false (default)：执行命令的所有验证和步骤，但不进行任何更改。完成后会显示一份报告。请参阅 测试 rebootClusterFromCompleteOutage。primary：实例定义，表示必须选择为主实例的实例。请参阅 使用 rebootClusterFromCompleteOutage 选择主节点。switchCommunicationStack: mysql | xcom: 重启后集群使用的Group Replication协议栈。请参阅 第 7.5.9 节，“配置组复制通信堆栈”。ipAllowListXCOM：使用协议栈 时允许连接到组复制流量实例的主机列表。localAddress：带有组复制本地地址的字符串值，而不是使用XCOM协议栈时自动生成的本地地址。
该force选项使您能够忽略集群成员的可用性或所选成员中的 GTID 集差异并重新启动集群。
例如，重启集群
myCluster：
JS> var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{force: true})force以下情况不允许使用
该选项：
如果 Cluster 属于一个 ClusterSet 并且是 INVALIDATED 或者主 Cluster 不在全局状态 OK，
Cluster 属于一个 ClusterSet，是主 Cluster，并且是 INVALIDATED。
无法添加或重新加入实例
rebootClusterFromCompleteOutage。如果您曾经force忽略无法访问的成员并重新启动集群，则必须使用
cluster.rejoinInstance()
您可以通过以下方式之一定义 Cluster primary：
-
在命令 中 定义
primary选项 。dba.rebootClusterFromCompleteOutage()例如，重新启动集群
myCluster并将在本地计算机上运行的成员设置为主要成员，端口为 4001：var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001"}) 通过在GTID 集低于另一个成员的集群成员上 使用
primary选项和 选项。force
您可以使用该
dryRun选项测试更改。此选项验证命令及其选项并生成结果日志。如果提议的更改有问题，则会抛出异常。
以下示例显示了重新启动集群的空运行myCluster，将主节点设置为在端口 4001 上运行的本地成员，以及它返回的日志消息：
JS > var cluster = dba.rebootClusterFromCompleteOutage("myCluster",{primary: "127.0.0.1:4001", dryRun: true})
NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
Cluster instances: '127.0.0.1:4000' (OFFLINE), '127.0.0.1:4001' (OFFLINE), '127.0.0.1:4002' (OFFLINE)
Switching over to instance '127.0.0.1:4001' to be used as seed.
dryRun finished.
rebootClusterFromCompleteOutage如果集群不满足要求，则执行以下检查并生成警告：
确认没有从 ClusterSet 中强制删除副本集群。
确认 ClusterSet 的主集群是可达的。
检查集群中是否存在非查看更改日志事件 (VCLE) 的错误事务。请参阅 分布式恢复的工作原理。
确认 Cluster 的已执行事务集 (
GTID_EXECUTED) 不为空。
该命令会自动将副本集群重新加入到 ClusterSet，确保为所有集群成员配置 ClusterSet 复制通道。