MongoDB 复制集频繁选举时，客户端会看到一种很典型的报错：not master 或 NotWritablePrimary，并伴随服务端日志中的 1650 错误码。这个错误码不是单纯的业务异常，它说明当前节点已经失去了主节点身份，或者一次新的选举刚刚被触发。很多团队在遇到这个错误时，第一反应是加大写重试次数，但这只能暂时掩盖问题，选举风暴仍在后台消耗资源，甚至会把所有写请求拖垮。
要彻底消除 1650，需要从复制集的心跳机制、选举超时参数、节点负载和网络质量四个方向同时检查。下面先拆解错误码对应的状态变化，再给出可执行的排查与调整步骤。
1650 错误码背后的选举机制
MongoDB 复制集采用基于 Raft 协议的选举模型。每个节点默认每 2 秒向其他成员发送一次心跳，如果从节点在 electionTimeoutMillis 设定的窗口内没有收到主节点的心跳，就会认为主节点失联，并发起一轮新选举。这个窗口默认是 10 秒，意味着一次 5 到 8 秒的磁盘 IO 阻塞或者网络抖动，都可能让从节点误判主节点已经宕机。
当选举发生时，原主节点会被迫降级为从节点，正在执行的写入可能返回 NotWritablePrimary，客户端就会看到 1650 相关错误。需要注意的是，1650 并不是表示数据损坏，而是表示当前节点在复制集拓扑中已经不再是主节点，或者它正在参与选举但尚未获得多数投票。频繁出现这一错误，说明复制集在短时间内多次发生主节点切换，也就是常说的选举风暴。
在日志中可以通过下面命令快速过滤出与选举相关的记录：
grep "1650\|election" /var/log/mongodb/mongod.log | tail -n 30
如果日志中多次出现 Starting an election、Step down 等关键字，并且时间间隔很短，基本可以确认选举过于频繁。
导致选举频繁的几类典型原因
第一种是网络层面的抖动。复制集节点如果跨机房或跨可用区部署，链路质量不稳定，2 秒一次的心跳很容易出现延迟或丢包。即使主节点本身没有故障，从节点也可能因为连续几次心跳超时而发起选举。这种情况下，适当调大心跳容忍窗口比频繁重试更有效。
第二种是磁盘性能不足。MongoDB 主节点需要把写入同步到 journal，如果磁盘 IO 延迟持续在几百毫秒甚至更高，心跳处理线程可能会被阻塞，导致从节点接收不到响应。这种场景常见于使用机械盘、云盘 IOPS 配额过低，或者数据增长后没有及时扩容。可以用 mongostat 观察 aw、fl 等指标是否异常。
第三种是复制集配置本身不合理。例如 electionTimeoutMillis 设置过小、多个节点优先级相同导致选举竞争，或者某些节点被配置为 votes: 1 但实际网络隔离，导致无法形成稳定多数派。还有一类情况是不同节点运行不同 MongoDB 版本，旧版本节点可能不兼容新选举协议，导致主节点频繁降级。
第四种是资源争用。CPU 被其他业务占满、内存不足触发 swap、容器限流等，都会让节点无法按时处理心跳。这类问题在云环境或混部机器上尤其常见。
通过 rs 命令定位选举问题
排查选举问题，第一步是查看当前复制集状态。登录到任意可用节点，执行 rs.status()，重点观察每个成员的 stateStr、health 和 lastHeartbeat。如果某个节点 lastHeartbeat 明显比其他节点大，说明它的心跳链路存在延迟。
rs.status().members.forEach(function(m) {
print(m.name, m.stateStr, m.health, m.lastHeartbeat);
});
第二步是检查复制集配置，确认每个节点的优先级和投票设置是否符合预期。下面是一个典型的三节点配置示例：
{
"_id": "rs0",
"version": 12,
"members": [
{ "_id": 0, "host": "mongo1:27017", "priority": 2 },
{ "_id": 1, "host": "mongo2:27017", "priority": 1 },
{ "_id": 2, "host": "mongo3:27017", "priority": 1 }
],
"settings": {
"heartbeatIntervalMillis": 2000,
"electionTimeoutMillis": 10000
}
}
如果一个主节点的优先级很高，但它的磁盘或网络不稳定，反而会加剧选举切换。常见做法是让性能最稳定的节点拥有最高优先级，同时保证多数派节点在同一网络区域内。
第三步是观察操作系统资源。可以使用 iostat -x 1 查看磁盘利用率，使用 vmstat 1 查看 CPU 和内存情况。如果磁盘的 %util 长期接近 100%，或者 svctm 很高，就需要先解决 IO 瓶颈，再调整复制集参数。
降低选举频率的调整方案
对于网络抖动或偶发延迟，最直接的方案是适当增加选举超时时间。将 electionTimeoutMillis 从默认的 10 秒调整到 15 秒或 20 秒，可以让节点对瞬时抖动有更强的容忍能力。需要注意的是，调整后一旦真实故障发生，从节点发起选举的时间也会相应变长，因此不要设置得过大。
var cfg = rs.conf();
cfg.settings = cfg.settings || {};
cfg.settings.electionTimeoutMillis = 15000;
rs.reconfig(cfg);
如果确认是磁盘性能导致主节点降级，应该优先将数据目录和日志目录迁移到高性能 SSD，并为 MongoDB 预留足够的 IOPS。对于云盘，可以提升盘的类型或容量以换取更高吞吐。还可以通过关闭无关后台任务来降低 IO 争抢。
如果选举频繁是由于节点优先级竞争引起的，可以手动设置固定的优先级，并让一个节点长期作为主节点。同时建议将 writeConcern 设置为 majority，虽然会增加少量写入延迟，但可以避免主节点在数据未同步到大多数节点时就已经接受写请求，从而减少降级后的数据回滚风险。
最后，不要忽视版本一致性。将复制集内所有节点的 MongoDB 版本升级到同一维护分支，并保持近期的补丁版本，可以避免因选举协议差异造成的无谓切换。
总结来说，1650 错误码频繁出现，本质上是复制集拓扑稳定性出了问题。通过延长选举窗口、优化磁盘与网络、调整优先级和统一版本，大多数选举风暴都能得到有效控制。排查时应以日志和 rs.status() 为依据，避免盲目重启节点，因为重启本身也可能触发新的选举。
MongoDB故障码1650复制集选举心跳超时修改时间：2026-10-05 11:56:31