electiontimeoutmillis 是主节点失联后触发新选举的等待时长，非连接超时；默认10秒，影响故障响应速度与集群稳定性，需配合 heartbeatintervalmillis 及网络、时钟等基础项协同调优。
electionTimeoutMillis 不是“连接超时”，它只影响主节点失联后的选举触发时机
很多人一看到“选举超时”就以为是客户端连不上副本集才设这个参数，其实完全不是一回事。electionTimeoutMillis 控制的是：当一个节点发现它「看不见大多数成员」或「收不到主节点心跳」后，要等多久才开始发起新选举。默认值是 10000（10 秒），它不决定你能不能连上、也不影响驱动选节点——那是 serverSelectionTimeoutMS 干的事。
常见误操作是把它调小到 5000 甚至 3000，结果网络抖动一下就触发选举，集群反复震荡；或者调大到 30000，真宕机了得等半分钟才降级，业务写入卡死。
- 局域网稳定环境：可设为
12000–15000，兼顾响应速度与抗抖动能力 - 跨可用区部署（如同城双中心）：建议
20000–25000，容忍骨干网偶发延迟 - 严禁在公网直连场景使用副本集——这不是调参能救的，该换架构
修改 electionTimeoutMillis 必须用 rs.reconfig()，且需多数节点在线
这个参数属于副本集配置项，不能靠启动参数或 adminCommand 动态改，必须走 rs.reconfig() 流程。而且执行时，必须有超过半数的节点处于 PRIMARY 或 SECONDARY 状态（不能是 STARTUP、RECOVERING 或离线），否则会报 NotEnoughMembers 错误。
实操步骤很简单，但容易漏关键点：
- 先运行
rs.conf()拿到当前配置对象 - 在
settings字段里加{"electionTimeoutMillis": 15000}（注意不是顶层字段） - 执行
rs.reconfig(cfg)，观察返回是否含"ok": 1 - 立刻跑
rs.status()确认所有节点optimeDate在推进，没出现HEARTBEAT失败
如果改完发现某个节点状态变成 UNKNOWN 或日志刷 could not reach node，大概率是网络或防火墙没通，不是参数问题。
heartbeatIntervalMillis 才是真正影响选举感知节奏的参数
electionTimeoutMillis 是“等多久才动”，而 heartbeatIntervalMillis 决定了“多久查一次心跳”。默认 2000 毫秒，意味着每 2 秒各节点互相发一次 isMaster 探测。如果链路延迟高或丢包，心跳包可能迟迟不到，electionTimeoutMillis 就成了摆设。
调整它比调 electionTimeoutMillis 更直接有效：
- 万兆内网/单机房：可降到
1000，加快故障感知 - 跨云厂商专线：保持
2000或略增至3000，避免因延迟波动误判 - 千万别设成
500—— 高频心跳会加重 mongod 负载，尤其 oplog 压力大的时候
这个参数也要统一改到所有节点的 rs.conf() 里，否则视图不一致会导致投票分裂。
选举失败根本不在超时参数上，先看这三件事
如果你改了 electionTimeoutMillis 还是频繁选举，90% 的情况跟参数无关。真正该盯住的是：
- DNS 解析失败：客户端解析出 IPv6 地址，但 MongoDB 只监听
127.0.0.1，加{ family: 4 }强制 IPv4 - 防火墙或安全组拦了 27017 端口：不只是入方向，出方向（比如从 secondary 到 primary 的心跳）也得放行
- 节点间时钟不同步：NTP 漂移 > 1 秒，心跳时间戳会被拒收，日志里会出现
Invalid clock skew
这些比任何超时参数都优先级更高——参数调得再准，连心跳都发不出去，选举永远卡在第一步。
