【MySQL Shell】9.7 强制（切换）一个新的主实例

与 InnoDB Cluster 不同，InnoDB ReplicaSet 不具备自动故障检测或基于共识的协议，例如组复制提供的协议。如果主实例不可用，则需要手动故障切换。一个丢失了主的 InnoDB ReplicaSet 实际上是只读的，要想进行任何写入更改，必须选择一个新的主。如果无法连接到主实例，并且无法使用 ReplicaSet.setPrimaryInstance() 安全地执行到新主实例的切换，如 第 9.6 节 “更改主实例” 中所述，请使用 ReplicaSet.forcePrimaryInstance() 操作执行主实例的强制故障切换。这是一种最终操作，只能在当前主系统不可用且无法以任何方式恢复的灾难类型场景中使用。

警告
强制故障切换是一种潜在的破坏性操作，必须谨慎使用。

如果目标实例不可访问（或为空），则会自动选择最新的实例并将其升级为新的主实例。如果目标实例可访问，则将其提升为新的主实例。其他可访问的辅助实例从这个新的主实例复制。目标实例必须在可访问的实例中拥有最新的 GTID_EXECUTED 集合， 否则操作失败。

故障切换与计划的更改主实例不同，因为它在不与旧的主要实例同步或更新的情况下升级次要实例。这会产生以下主要后果：

• 在旧主实例发生故障时，辅助服务器尚未应用的任何事务都将丢失。
• 如果旧的主实例仍在运行和处理事务，则会出现脑裂，新、旧主实例的数据集会出现分歧。

如果最后一个已知的主对象仍然可以访问，则 ReplicaSet.forcePrimaryInstance() 操作将失败，以减少出现脑裂情况的风险。但是，管理员有责任确保其他实例无法访问旧的主实例，以防止或最小化这种情况。

强制故障切换后，新主实例将认为旧主实例无效，并且不能再成为 ReplicaSet 的一部分。如果您稍后找到可以恢复的实例，则必须将其从 ReplicaSet 中删除，并将其作为新实例添加。如果在故障切换期间无法将辅助实例切换到新的主实例，则认为该辅助实例无效。

故障切换后可能会丢失数据，因为旧的主实例可能具有尚未复制到正在升级的辅助服务器的事务。此外，如果被假设发生故障的实例仍然可以处理事务，例如，因为它所在的网络仍在运行，但无法从 MySQL Shell 访问，那么它将继续与升级的实例分离。一旦实例上的事务集发生分歧，就需要手动干预才能恢复，并且在某些情况下无法恢复，即使失败的实例可以恢复。通常，从需要强制故障切换的灾难中恢复的最快和最简单的方法是丢弃这些分歧的事务，并从新升级的主实例重新调配新实例。