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

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

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

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

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

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

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

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

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