优先级通过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 节点,否则 rs.reconfig() 会报错 not master。secondary 节点只读,不接受配置变更。
mongo --host --port 连接,别连错节点rs.status() 看 stateStr 字段为 PRIMARY 的那个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 是否匹配预期MongoDB 强制要求:priority 为 0 的节点,如果还保留 votes=1,rs.reconfig() 会拒绝提交并报错 cannot have votes > 0 when priority is 0。
priority=0 + hidden=true + votes=0
priority=0 且 votes=1,这是特例,允许存在priority 改成 0 却没动 votes,配置会失败,得回退再重试哪怕只改一个 priority 字段,MongoDB 也会认为配置有变,可能让当前 primary 主动 stepDown,引发一次选举——这不是 bug,是设计行为。
NotPrimaryNoSecondaryOk 或超时rs.stepDown() 手动触发一次选举,观察恢复时间rs.status(),确认新 primary 已就位、所有 secondary 的 optimeDate 没严重落后真正麻烦的不是改 priority 这几步,而是改完之后没人盯 rs.status() 输出里的 optimeDiffs 和 lastHeartbeatRecv——延迟高或心跳断的节点,就算 priority 再高也永远不会被选上。
DeepSeek多模态怎么样及保姆级配置教程(codex、claude)实用指南
WSL2+Docker+Ollama本地部署大模型思路和实践指南(Qwen1.8b)实用指南
DeepSeek Harness热门插件盘点:10个实用插件,覆盖多Agent、上下文和多模态实用指南
grep文本搜索与正则表达式完整代码示例实用指南
AI漫剧伪装直男1‑24集无雾版夸克网盘资源免费分享
AI漫剧玉僧入尘1-68集无雾无删版夸克网盘资源免费分享