与 InnoDB Cluster 不同，InnoDB Cluster 支持在主实例意外故障时自动故障转移，而 InnoDB 副本集没有自动故障检测或组复制提供的基于共识的协议。如果主实例不可用，则需要手动故障转移。丢失主实例的 InnoDB 副本集实际上是只读的，要进行任何写更改，必须选择一个新的主实例。如果您无法连接到主实例，并且无法使用 ReplicaSet.setPrimaryInstance() 安全地执行到新主实例的切换，如 第 9.7 节“更改主实例” 中所述，请使用 ReplicaSet.forcePrimaryInstance() 操作执行主实例的强制故障转移。这是最后的手段操作，只能在当前主实例不可用且无法以任何方式恢复的灾难情况下使用。

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

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

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

强制故障转移后，新主实例会将旧主实例视为无效，并且该实例不再属于副本集。如果稍后您发现可以恢复的实例，则必须将其从副本集中移除，并将其作为新实例添加。如果辅助实例在故障转移期间无法切换到新主实例，则该实例被视为无效。

故障转移后可能会出现数据丢失，因为旧主实例可能具有一些尚未复制到正在提升的辅助实例的事务。此外，如果假定已故障的实例仍可以处理事务，例如，因为它所在的网络仍在运行但 MySQL Shell 无法访问，则该实例将继续与已提升的实例发生分歧。在实例上的事务集发生分歧后进行恢复需要手动干预，并且在某些情况下可能无法实现，即使可以恢复故障实例。通常，从需要强制故障转移的灾难中恢复的最快、最简单的方法是丢弃此类分歧的事务，并从新提升的主实例重新配置新实例。