MongoDB副本集在运行过程中可能突然出现故障码120，提示副本集选举失败，此时集群无法选出新的主节点，写操作被拒绝，应用层会收到异常。要理解这个故障，必须先弄清楚副本集的选举机制：MongoDB依靠节点之间的心跳和投票在多数派存活时选出主节点，一旦无法达成多数，就会抛出120相关错误。本文从原理、排查、修复三个层面详细说明应对方法。
副本集选举机制与故障码120的成因
MongoDB副本集内部每个节点默认每两秒发送一次心跳，通过replSetGetStatus可以观察到lastHeartbeat和stateStr。当某个节点在electionTimeoutMillis时间内没有收到多数节点的合法响应，就会触发选举，但如果存活节点数少于总票数的一半，选举必然失败，服务端以故障码120形式上报。这种设计是为了防止脑裂，但也意味着任何导致多数派离线的原因都会直接引发该错误。
除了网络分区，配置错误也是常见诱因。例如管理员将某些节点的votes设为0却误改了priority，或者新增隐藏节点时未正确计算投票权重，都会让原本可行的多数派变成不可能。还有一种情况是oplog断裂：某个节点落后太多，在选举时因为数据不一致被拒绝投票，从而变相减少可用票数。理解这些底层逻辑，才能避免只重启服务却不解决根本问题。
从日志层面看，故障码120往往伴随“could not find primary”或“not enough voting members”等记录。MongoDB不会自动绕过选举门槛，因此人为干预时必须先读懂rs.status()里的members数组，而不是盲目调大超时时间。超时过长只会让故障隐蔽化，并不会消除多数派缺失的事实。
分步排查故障码120的实用方法
第一步应当登录任意存活节点，执行rs.status()并检查每个成员的health与stateStr。如果看到多个节点stateStr为UNKNOWN或DOWN，说明心跳已断。此时用ping和telnet确认端口27017是否通，特别要注意云环境的安全组是否误删了节点间互访规则。很多现场故障其实是运维变更网络策略后未通知数据库团队，导致心跳包被丢弃。
第二步统计投票权。在mongo shell中运行如下命令可快速算出当前配置里的有效票数：
// 统计副本集配置中的投票总数与在线可投票节点数
var cfg = rs.conf();
var totalVotes = 0;
var aliveVotes = 0;
cfg.members.forEach(function(m){
if(m.votes === 1){
totalVotes++;
// 假设通过外部探测已知节点存活，这里仅示例逻辑
if(m.hidden !== true){
aliveVotes++;
}
}
});
print("总票数:" + totalVotes + " 在线可投票:" + aliveVotes);
如果aliveVotes小于等于totalVotes/2，那么选举失败是符合预期的。此时必须恢复离线节点或临时缩减投票成员。第三步检查oplog：用db.getReplicationInfo()对比各节点optime，发现某个节点延迟超过electionTimeout对应的数据量，应先让其重新同步而非强行推举。
此外，还应排查是否有人误执行过rs.reconfig而没有force选项。在多数派丢失时普通reconfig会直接报错，但部分自动化脚本会捕获异常后重试，造成配置版本混乱。通过查看local库中system.replset文档的version字段，可以判断是否配置被反复篡改。
安全修复与避免再次触发选举失败
当确认多数节点永久不可用，例如三节点中两台磁盘损坏，就需要用存活节点以force方式重配。操作前务必备份原cfg，然后删减失效成员并降低总票数，使存活节点构成多数。示例如下：
// 在唯一存活节点上强制重配副本集
var cfg = rs.conf();
cfg.members = [cfg.members[0]]; // 仅保留当前节点
cfg.version = cfg.version + 1;
rs.reconfig(cfg, {force: true});
强制重配后，该节点会成为单节点主库，业务恢复写能力，但已失去高可用。后续应尽早补齐节点并用rs.add重新引入，且新节点最好先做全量初始化，避免带着断裂oplog加入。修复过程中严禁在多节点同时执行force，否则会出现多个独立主节点，数据将无法自动合并。
为了长期规避故障码120，部署时应采用奇数个投票节点，或引入仲裁节点但不给其数据压力。监控上要把rs.status()的member状态与心跳延迟接入告警，在多数派临界前通知人处理。同时规范变更流程：任何rs.reconfig都必须先在测试环境验证vote计算，禁止在业务高峰直接操作。这样能从架构和流程两端消灭选举失败的大部分根源。
最后补充一点，MongoDB不同大版本对选举超时的默认值略有差异，升级前应在文档确认electionTimeoutMillis范围，避免新版更敏感的心跳机制在弱网络下频繁触发120。保持节点间时钟同步、控制副本集跨可用区延迟，也是隐形却关键的基础工作。