优先级通过rs.conf()获取配置、修改members[n].priority、再用rs.reconfig(cfg)提交，值范围0–1000；priority=0节点永不能成为primary，且必须同时设votes=0或hidden=true；操作须连当前primary，修改前需确认members索引，避免误配。

直接说结论：优先级通过 rs.conf() 获取配置、修改 members[n].priority、再用 rs.reconfig(cfg) 提交，值范围是 0–1000，priority=0 的节点永远不能成为 primary。

连接到 primary 后才能改 priority

必须连上当前的 primary 节点，否则 rs.reconfig() 会报错 not master。secondary 节点只读，不接受配置变更。

• 用 mongo --host --port 连接，别连错节点
• 不确定谁是 primary？先执行 rs.status() 看 stateStr 字段为 PRIMARY 的那个
• 如果当前 primary 刚宕过、还没选出来，整个副本集处于不可写状态，此时改 priority 会失败

修改 members[n].priority 时索引容易搞错

members 数组下标从 0 开始，但下标和节点的 _id 不是一回事——这是最常踩的坑。

• 执行 cfg = rs.conf() 后，先打印 cfg.members，确认你要改的节点在第几个位置（比如 host: "node3:27017" 在 members[2]）
• 不要凭记忆写 cfg.members[0].priority = 2，除非你刚确认过 members[0] 确实是你想调的节点
• 修改后务必检查：cfg.members[2].host 和 cfg.members[2].priority 是否匹配预期

priority=0 的节点必须同时满足 votes=0 或 hidden=true

MongoDB 强制要求：priority 为 0 的节点，如果还保留 votes=1，rs.reconfig() 会拒绝提交并报错 cannot have votes > 0 when priority is 0。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 想让某节点只做备份不参与选举？设 priority=0 + hidden=true + votes=0
• 仲裁节点（arbiter）默认 priority=0 且 votes=1，这是特例，允许存在
• 如果误把一个正常 secondary 的 priority 改成 0 却没动 votes，配置会失败，得回退再重试

rs.reconfig() 可能触发强制选举

哪怕只改一个 priority 字段，MongoDB 也会认为配置有变，可能让当前 primary 主动 stepDown，引发一次选举——这不是 bug，是设计行为。

• 选举期间写入中断，通常持续 10–20 秒，客户端会收到 NotPrimaryNoSecondaryOk 或超时
• 别在流量高峰改；如果业务对可用性极其敏感，建议提前用 rs.stepDown() 手动触发一次选举，观察恢复时间
• 改完立刻跑 rs.status()，确认新 primary 已就位、所有 secondary 的 optimeDate 没严重落后

真正麻烦的不是改 priority 这几步，而是改完之后没人盯 rs.status() 输出里的 optimeDiffs 和 lastHeartbeatRecv——延迟高或心跳断的节点，就算 priority 再高也永远不会被选上。