优先级通过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 <primary_host> --port <primary_port></primary_port></primary_host>连接，别连错节点 - 不确定谁是 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。
- 想让某节点只做备份不参与选举？设
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 再高也永远不会被选上。
