安全缩容副本集需先降级待删节点参选资格：将其priority设为0，确保仅一个secondary保持priority>0，再执行rs.remove()；否则可能触发选举。
缩容副本集时，只要操作得当，完全可以避免触发选举——关键不是“能不能”，而是“怎么删”。直接 rs.remove() 某个节点，如果它当前是 PRIMARY 或参与选举的 SECONDARY，就可能引发重新选主；而正确做法是先让它退出选举资格，再安全移除。
为什么 rs.remove() 有时会触发选举？
rs.remove() 本身不强制选举，但若被删节点是当前 PRIMARY，或其 priority > 0 且其他 SECONDARY 有参选资格，MongoDB 会在配置变更后立即触发一次选举来补位。这不是 bug，而是副本集自动维持高可用的机制。
- PRIMARY 节点不能被
rs.remove()直接删掉（会报错），必须先rs.stepDown() - SECONDARY 节点若
priority > 0，删除后剩余节点中 priority 最高的那个大概率会被推为新 PRIMARY - 即使你只删一个低 priority 节点，只要集群里还有多个
priority > 0的 SECONDARY，选举仍可能发生（尤其网络抖动时）
缩容前必须做的三件事
目标：让待删节点彻底失去参选能力，并确保剩余节点中最多只有一个 priority > 0 的可参选成员。
- 在 PRIMARY 上执行
rs.conf()获取当前配置，存为cfg - 将待删节点的
priority设为0（哪怕它已是 SECONDARY），并确认其votes: 1未被禁用（否则rs.reconfig()可能失败） - 检查其余所有 SECONDARY 节点的
priority：只保留一个设为1（或更高），其余全部设为0；PRIMARY 的priority必须 > 0（MongoDB 强制校验） - 调用
rs.reconfig(cfg, {force: true})应用变更，等待状态稳定（rs.status().myState === 1）
真正安全删节点的命令和时机
等上一步 reconfig 完成、所有成员状态同步完毕（通常 10–30 秒），再执行删除：
- 用
rs.remove("host:port")删除目标节点 —— 此时它已是priority: 0且不参与投票，删它不会动摇 PRIMARY 地位 - 不要用
cfg.members.splice()+rs.reconfig()替代rs.remove()：前者容易漏掉隐式字段（如_id），导致配置校验失败或意外降级 - 删完立刻运行
rs.status()确认该节点已从members数组消失，且primary字段未变
最容易被忽略的一点：缩容后别忘了清理下线节点的磁盘数据和进程。MongoDB 不会自动回收它的 dbpath，残留的旧数据文件如果误启动，可能因 oplog 截断或 term 冲突导致整个副本集卡住同步。
