设置priority=0能防止从节点升主，因为该值是选举硬性排除规则，使节点彻底丧失参选资格，即使数据最新、网络通畅也无法被投票选为primary。
为什么设置 priority=0 能防止从节点升主
副本集选举时，priority 是决定节点能否参选、以及被选中的权重关键参数。值为 0 的节点明确表示“永不参与主节点选举”，即使它数据最新、网络通畅、健康状态良好，也不会被投票选为主节点。这不是临时禁用，而是配置级的硬性排除。
注意：priority 只影响选举行为，不影响同步、读取或复制功能；该节点仍会持续拉取 oplog、保持数据最新，只是彻底放弃“上位”资格。
如何安全地将某个从节点 priority 设为 0
操作必须在连接到当前 PRIMARY 节点的 mongosh 中执行，且需确保配置变更原子生效：
- 先获取当前配置：
cfg = rs.conf() - 确认目标节点索引（比如第三个成员）：
cfg.members[2]—— 注意数组下标从 0 开始，别数错 - 设优先级为 0：
cfg.members[2].priority = 0 - **必须显式调用重配置**：
rs.reconfig(cfg)，否则修改仅存于变量中，不落地 - 执行后立刻用
rs.status()检查stateStr和priority字段是否已更新
常见错误：直接改 rs.conf().members[2].priority 后没调 rs.reconfig()，导致配置看似改了，实则完全无效。
priority=0 后还可能意外变主吗
正常情况下不会，但有两类边界情况需警惕：
- 如果整个副本集只剩这一个存活节点（其他全宕），且
force: true强制重配置，MongoDB 可能绕过 priority 约束让它上位 —— 这属于极端故障兜底机制，不是常规路径 - 若该节点曾被手动用
rs.stepDown()降级，而此时其他节点全部不可达，它仍不会自动升主，因为 priority=0 的约束在选举逻辑中早于健康检查介入 - 配置写错索引（如把
[1]写成[0]）会导致错误节点被锁死，务必核对host字段匹配实际节点地址
priority=0 和 hidden/arbiters 的区别
三者都可用于控制节点角色，但语义和用途不同：
-
priority=0：节点仍在选举池中，只是权重为零；它参与心跳、同步、投票（除主票外），适合“备用只读节点” -
hidden: true：节点对客户端不可见，也不参与选举，常用于备份专用节点或延迟同步场景 -
arbiterOnly: true：纯仲裁节点，不存数据，只投票，不能设priority=0（默认就是 0，且不可改）
混用时注意：一个节点可同时设 priority=0 和 hidden=true，但没必要；优先级为 0 已足够阻止升主，加 hidden 反而让运维排查更难定位该节点。
