MongoDB副本集选举不看启动顺序，只依据priority权重和oplog同步进度；priority范围0–1000，默认1，设0则永不参选；修改需连Primary执行rs.reconfig()，且oplog落后超10秒将失去参选资格。

副本集选举不看“谁先启动”，只看优先级+数据同步状态

MongoDB 副本集的 Primary 选举不是按启动顺序排队，也不是谁 ping 得快谁上；它本质是一场带权重的投票——priority 是核心加权项，但光有高 priority 不顶用，optime（oplog 同步进度）必须够新。如果一个 priority=5 的节点 oplog 落后主节点 2 分钟，它大概率会被跳过，哪怕其他节点 priority 只有 1。

• priority 取值范围是 0–1000，默认为 1；设为 0 表示该节点永远不能成为 Primary，也不能发起选举（常用于备份节点或延迟从库）
• 修改 priority 必须通过 rs.reconfig()，不能直接改 rs.conf() 返回的对象——那是只读副本
• 选举前所有参与节点必须能互相心跳（默认 heartbeatTimeoutMillis=10000），且至少有 (N/2 + 1) 个有投票权的节点在线（N 是总投票成员数）

怎么安全调高某节点的 priority 并生效

别连 secondary 改配置，也别在业务高峰期执行；必须连到当前 Primary 执行，否则 rs.reconfig() 会报 NotMaster 错误。

• 先查当前配置：cfg = rs.conf()
• 定位目标成员（注意索引可能变）：cfg.members.find(m => m.host === "node3.example.com:27017")，然后记下它的 _id 或数组下标
• 改 priority（比如设为 3）：cfg.members[2].priority = 3（假设它是第 3 个成员）
• 强制重载配置：rs.reconfig(cfg, {force: true}) —— 加 {force: true} 是为了绕过“多数节点不可达”时的校验（仅限紧急恢复场景，平时不用）

执行后，原 Primary 可能立即 stepDown（尤其当新 priority 节点数据足够新），整个过程通常 5–15 秒，期间写入会短暂阻塞。

为什么改了 priority 却没当选 Primary？常见三类漏判

Priority 高 ≠ 自动上位。选举失败往往卡在隐性条件上，而不是配置本身写错了。

• oplog 进度太旧：用 rs.printSecondaryReplicationInfo() 看各节点落后多少秒；若 > catchUpTimeoutMillis（默认 10 秒），该节点直接失去参选资格
• 投票权被禁用：检查 cfg.members[i].votes 是否为 0（默认是 1）；votes=0 的节点不参与投票，也不被投票
• 网络分区残留：曾发生过网络抖动的节点，可能还缓存着旧 term 或 vote 请求；重启 mongod 进程可清空状态（比 rs.stepDown() 更彻底）

raft 协议？MongoDB 其实没用 Raft

MongoDB 副本集用的是自己实现的 election protocol v1（基于 Paxos 思想改良），不是 Raft。虽然都靠多数派投票、term 递增、log 匹配等机制保证一致性，但细节差异很大——比如 MongoDB 没有 leader lease，也没有 Raft 的 pre-vote 阶段；它的 electionTimeoutMillis 是随机漂移的（避免多个节点同时发起选举导致分裂投票）。

所以别套用 Raft 教程去调 heartbeat.interval 或模拟 follower timeout；MongoDB 的故障转移节奏由 settings.electionTimeoutMillis（默认 10s）、protocolVersion: 1 和 catchUpTimeoutMillis 共同决定，其中后者才是影响“能否抢在 w:1 写入丢失前完成切换”的关键参数。

真正容易被忽略的，是 priority 修改后不会立刻触发选举——得等下次心跳超时或主动 stepDown；而 oplog 同步延迟这种“看不见”的状态，往往比配置本身更早卡住整个流程。