共识集群失去多数派会发生什么？

简化版

共识集群失去多数派后无法安全提交新写、完成选举或确认线性一致读，通常应停止这些操作，而不是在少数派上继续返回成功。已提交数据不会因此消失，节点可继续提供明确标注的陈旧只读、健康检查或管理能力。恢复多数派后重新选举并修复日志；强制重建集群属于灾难恢复，必须先隔离旧节点，避免形成两个集群。

5 个 voter 至少需要 3 个响应，剩 2 个时任何一方都不能证明没有另一个合法多数派。旧 Leader 可能短暂仍认为自己在任，但无法复制到 quorum，因此不能推进 commitIndex。超时客户端不知道请求最终是否提交，必须使用幂等键查询或重试。

恢复方式优先修复网络或节点，让原配置重新形成多数派。不要通过临时把 5 节点配置改成 2 节点绕过协议，因为成员变更本身也需要旧 quorum 提交。确需 force-new-cluster 时要确认旧集群永不再服务、保存日志与任期并执行人工审批。

任意两个多数派必然相交。交点把此前接受或提交的信息传给新决议。失去多数派后，少数节点无法证明另一个分区没有更新状态。

停止写不是保守过度，而是避免两个分区都对同一业务承诺成功。

系统必须把弱读接口与线性一致读接口区分清楚。

旧 Leader 可能直到心跳失败或租约过期才意识到隔离。它可以把请求暂存或追加为未提交日志，但不能对客户端宣称提交成功。更稳妥的实现会在无法联系多数派后快速退化或拒绝写，减少不确定请求。恢复后这些未提交后缀可能被新 Leader 截断。

请求在多数派刚确认时响应丢失，客户端看到超时但写可能已经提交。所以“超时”不能等同于“失败”。客户端带 requestId 重试，状态机维护去重结果，或提供按 requestId 查询。对扣款等操作，盲目生成新请求会造成重复副作用。

先排查网络、DNS、证书、磁盘和进程，让足够的原 voter 恢复。 5 节点只需恢复到 3 个相互连通，就可选举和继续。恢复节点比较 term 与日志，由合法 Leader 修复冲突后缀。不要同时手工修改多个节点的成员文件。

成员变更改变 quorum 定义，本身必须由当前配置安全批准。 2 个幸存节点把配置改成 2 节点，而另外 3 个随后恢复，可能出现两个自认合法集群。

partition A: 2 nodes -> forced new config
partition B: 3 nodes -> original majority
both serving writes => split brain

这是数据分叉而非普通运维故障。

当多数节点永久丢失，只能从最可信、最新的幸存日志或备份重建。必须 fencing 旧节点、吊销凭证和阻断网络，确保它们不能恢复服务。记录数据丢失边界、最后提交索引和 RPO，经过审批后创建新集群身份。随后对业务做对账，而不是声称协议保证了零丢失。