与支持在主节点意外故障时自动故障转移的 InnoDB Cluster 不同，InnoDB ReplicaSet 没有自动故障检测或基于共识的协议，例如 Group Replication 提供的协议。如果主服务器不可用，则需要手动故障转移。失去主副本的 InnoDB ReplicaSet 实际上是只读的，并且为了使任何写更改成为可能，必须选择一个新的主副本。如果您无法连接到主实例，并且无法 按照第 9.6 节“更改主实例”ReplicaSet.setPrimaryInstance() 所述安全地执行到新主实例的切换 ，请使用 ReplicaSet.forcePrimaryInstance() 执行主节点强制故障转移的操作。这是不得已的操作，只能在当前主节点不可用且无法以任何方式恢复的灾难类型场景中使用。

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

故障转移不同于计划中的主实例更改，因为它会提升辅助实例而不与旧的主实例同步或更新旧的主实例。这具有以下主要后果：

如果最后一个已知的主节点仍然可以访问，则 ReplicaSet.forcePrimaryInstance() 操作失败，以降低出现裂脑情况的风险。但管理员有责任确保其他实例无法访问旧的主实例，以防止或最大程度地减少此类情况。

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

故障转移后可能会丢失数据，因为旧的主数据库可能具有尚未复制到正在升级的辅助数据库的事务。此外，如果被假定失败的实例仍然可以处理事务，例如因为它所在的网络仍在运行但无法从 MySQL Shell 访问，它会继续从提升的实例中分离出来。一旦实例上的事务集发生分歧，就需要手动干预进行恢复，并且在某些情况下是不可能的，即使失败的实例可以恢复。经常，