priority最大值为1000，自MongoDB 3.6起支持0.0–1000.0浮点数；设为1000仅提升选举权重，能否当选Primary还取决于oplog同步进度、节点状态及投票资格。
priority 最大值是 1000，不是 100
很多老文档或博客写 priority 范围是 0–100，那是 MongoDB 3.6 之前的旧说法。自 MongoDB 3.6 起，priority 明确支持 0.0 到 1000.0 的浮点数，官方文档已更新。设成 1000 是合法且有效的，但不等于“一定当选”——它只影响选举时的权重排序，最终是否成为 Primary 还取决于 oplog 同步进度、健康状态和投票成员数。
为什么设到 1000 也不保险？关键限制在 oplog 和投票资格
即使把某个节点 priority 设为 1000，它仍可能被跳过选举，常见原因包括：
-
oplog落后主节点超10秒（默认阈值），该节点自动失去参选资格 - 节点状态不是
PRIMARY或SECONDARY（比如是RECOVERING或STARTUP2） - 该节点
votes: 0（例如仲裁者或手动禁用投票），即使priority > 0也无法参与投票 - 副本集总投票成员数不足奇数，或多数派无法达成（如 3 节点中 2 个宕机）
修改 priority 必须连 Primary 执行 rs.reconfig()，且不能直接改 _id
修改必须在当前 PRIMARY 节点上操作，否则报错 not master。配置过程容易出错的地方有：
- 误把
members[n]._id当作数组下标 —— 实际要用members数组的**索引位置**（从 0 开始），不是成员的_id字段值 - 没先执行
cfg = rs.conf()就直接改cfg.members[0].priority，会提示ReferenceError - 修改后没调用
rs.reconfig(cfg)，或调用时忘了加括号导致静默失败 - 修改过程中 Primary 切换，导致 reconfig 被中断，需重试
示例正确流程：
cfg = rs.conf()<br>cfg.members[2].priority = 1000<br>rs.reconfig(cfg)
priority = 0 的节点仍可同步数据，但彻底退出选举博弈
设 priority: 0 是最稳妥的“防升主”手段，适用于延迟节点、隐藏节点或仅作灾备的冷备节点。注意：
-
priority: 0的节点默认votes: 0（除非显式设votes: 1），但它依然能拉取 oplog、保持数据最新 - 仲裁者（arbiter）强制
priority: 0，且不能设votes: 1以外的值 - 如果所有非-arbiter 成员都设了
priority: 0，副本集将无法选出 Primary，整个集群只读
真正难处理的从来不是怎么设高 priority，而是如何让高 priority 节点在故障时**及时跟上 oplog** 并**保持在线投票资格**——这比调数字重要得多。
