priority 0 的 mongodb 副本集成员永不参选且不被选为主节点，但仍可复制数据、响应读请求并参与投票（votes>0时），适用于跨机房主节点锁定或热备份场景。
priority 0 的 MongoDB 副本集成员，核心作用就是：永不参选、永不被选为主节点，但依然能复制数据、响应读请求、参与投票（前提是 votes > 0）。 它不是“废节点”，而是有明确战术定位的可控成员——比如跨机房部署时把远端从节点设为 priority: 0，就能确保主节点永远落在低延迟数据中心；又或者用它当热备份，数据时刻同步，但绝不干扰主节点稳定性。
为什么不能只靠 hidden 或 slaveDelay 实现相同效果
hidden 成员默认 priority: 0 且 votes: 0，对客户端不可见，也不能参与“majority”写关注确认；slaveDelay 成员可以延迟同步，但若没配 priority: 0，它仍可能在极端网络分区下被选为主节点——这会直接导致数据陈旧写入。而纯 priority: 0 成员保留了全部复制和读能力，只关闭选举通道，控制粒度更精准。
-
hidden: true→ 自动锁定priority: 0和votes: 0，无法参与w: "majority"确认 -
slaveDelay: 3600→ 数据滞后 1 小时，但若未设priority: 0，它仍可能在选举中胜出 -
priority: 0→ 复制照常、读请求照接、oplog 同步不中断，仅拒绝成为 primary
配置 priority 0 节点时必须同步检查 votes
priority 和 votes 是强绑定关系：MongoDB 明确要求 votes: 0 的节点必须 priority: 0，反过来，priority > 0 的节点也必须 votes: 1。但关键陷阱在于：一个 priority: 0 节点如果同时 votes: 0，它就无法帮集群达成“majority”写关注所需的法定人数——比如 3 节点副本集，若把第 3 个节点设为 priority: 0, votes: 0，那剩下两个节点永远凑不够多数（2/3），所有 w: "majority" 写入都会卡住或超时。
- 要让它支持
w: "majority"→ 必须设votes: 1（即使priority: 0） - 已有 7 个投票节点 → 新增
priority: 0成员也必须设votes: 0，否则 reconfig 会失败 - 修改前先运行
rs.conf()确认当前投票节点数，避免意外突破 7 限制
如何安全地把现有 secondary 设为 priority 0
直接改配置会触发强制重选举，当前 primary 会断连并下线——这不是原子操作，期间写入会失败。务必在维护窗口执行，且按顺序操作：
- 先在 mongosh 中执行
cfg = rs.conf()拿到当前配置 - 定位目标成员索引（如
cfg.members[2]），设置cfg.members[2].priority = 0 - 确认该成员
votes值：若需参与 majority 投票，保留cfg.members[2].votes = 1；若只是冷备且已有 7 个投票节点，则必须设为0 - 执行
rs.reconfig(cfg, {force: true})—— force 是必需的，因为 priority 变更被视为高风险操作 - 立刻跟
rs.status()验证状态，观察是否出现"stateStr" : "SECONDARY"且"priority" : 0
真正容易被忽略的是：priority 0 节点一旦被错误地赋予了 votes: 0，它不会报错，但整个副本集的写关注语义会静默降级——你得主动查 replSetGetStatus.writableVotingMembersCount 才能发现法定人数已不足。
