主节点宕机后副本集不会立刻选出新primary，需等待心跳超时（默认10秒，2秒间隔连续失败）、确认失联并完成投票，全程通常12–30秒；electiontimeoutmillis从最后一次心跳起算，非宕机起始计时，且不可动态修改，须全节点一致配置并重启生效。
主节点宕机后，副本集不会立刻选出新 Primary——它得等心跳超时、确认失联、再走投票流程。整个过程通常 12–30 秒，期间写操作全部阻塞。
electionTimeoutMillis 超时是怎么触发的
Secondary 每 2 秒收一次 heartbeat，连续收不到 electionTimeoutMillis（默认 10000 毫秒）就判定 Primary 失联。这个值不是“从宕机开始倒计时”，而是从最后一次收到心跳起算。
- 网络抖动可能导致误判：比如刚好卡在第 9 秒断连，第 11 秒恢复，但 Secondary 已发起选举
- 不能单纯调小这个值来加速 failover——太小会频繁误触发；太大则写服务中断太久
- 修改需用
rs.reconfig()更新settings.electionTimeoutMillis，且所有节点必须在线才能生效
为什么我的高 priority 节点没当选
priority 只是加权项，不是免死金牌。真正卡住选举的往往是隐性条件：
-
oplog落后超过catchUpTimeoutMillis（默认 10 秒）：用rs.printSecondaryReplicationInfo()看各节点落后秒数，>10 秒直接失去参选资格 - 节点
votes: 0：即使 priority=5，若cfg.members[i].votes === 0，它既不投票也不被投票 - 旧 term 缓存残留：曾经历网络分区的节点可能还记着上一轮投票状态，
mongod进程重启比rs.stepDown()更彻底清空
w: "majority" 写关注对选举结果的影响
它不直接影响谁当选，但决定“谁当选之后数据是否可信”：
- 没配
w: "majority"时，写入只落盘 Primary 就返回，宕机后这部分数据大概率丢失 - 配了之后，Primary 必须等多数节点同步完 oplog 才确认写入，新当选的 Primary 至少拥有这些已确认的数据
- 但要注意：
wtimeout设太短（如 1000ms）可能让写操作因等待超时而失败，尤其在选举窗口期网络不稳定时
真正容易被忽略的是：选举完成 ≠ 数据可用。新 Primary 上位后，如果旧 Primary 突然恢复且仍能响应客户端，而应用没做连接重试或没启用 readConcern: "majority"，就可能读到即将回滚的脏数据。
