rs.stepDown()仅触发选举而非立即切换，成功需满足节点状态正常、优先级合理及网络可达；失败常见于无同步Secondary、长事务阻塞、非Primary执行或连接中断。
rs.stepDown() 不是“一键切换”，它只是触发选举的起点；真正完成切换，得看节点状态、优先级和网络是否满足条件。
rs.stepDown() 执行失败的常见原因
直接在 Primary 上运行 rs.stepDown() 却没反应，或报错退出，大概率是以下几种情况：
- 当前没有 Secondary 节点处于同步状态（
optime落后太多），rs.stepDown()会卡在追赶期，默认等待 10 秒（secondaryCatchUpPeriodSecs），超时就失败 - 执行时有长事务、索引构建或大量写入未提交，
rs.stepDown()会先尝试终止这些操作，失败则拒绝降级 - 命令在非 Primary 节点上运行，直接报
Error: not master - 客户端连接被强制断开后 shell 自动退出，误以为命令没生效——其实它已发出去，只是你收不到返回
为什么 rs.stepDown() 后 Primary 没变？
执行成功 ≠ 立刻换主。MongoDB 的选举逻辑不会跳过健康 Primary，除非它主动退位或失联。所以即使 rs.stepDown() 返回成功，也可能出现：
- 原 Primary 降级为 Secondary 后，又在
stepDownSecs时间内重新参选并赢回 Primary（尤其当其他节点优先级相同、数据也同步） - 多个 Secondary 优先级一样，选举结果取决于心跳响应速度和
optime新鲜度，不是随机也不是按顺序 - 某个 Secondary 处于
STARTUP2或RECOVERING状态，不参与选举，导致只剩一个合格节点，但 MongoDB 要求多数派（majority）才能选出 Primary，于是卡住
如何让目标节点稳稳成为新 Primary
单靠 rs.stepDown() 不够，得配合优先级控制和冻结策略：
- 先在目标 Secondary 上执行
rs.freeze(300)（冻结 5 分钟），防止它在你调优期间意外参选 - 在当前 Primary 上执行
rs.stepDown(60)，让它退位并禁选 60 秒 - 立刻修改副本集配置：用
cfg = rs.conf()拿到配置 → 改cfg.members[x].priority→cfg.version++→rs.reconfig(cfg) - 再对目标节点解冻：
rs.freeze()（不带参数即清除冻结） - 最后确认：
rs.isMaster().primary和rs.status().myState（注意后者是本节点状态，不是全局）
容易被忽略的兼容性细节
不同 MongoDB 版本对 rs.stepDown() 的行为略有差异：
- 4.2+ 默认启用
electionTimeoutMillis=10000，选举通常 10 秒内完成；低于 4.0 可能更慢 - 如果副本集启用了
chainingAllowed: false，Secondary 只能从 Primary 同步，一旦 Primary 退位且无直连路径，同步会中断 -
rs.stepDown()会中断所有活跃连接，包括应用连接池里的连接，客户端必须支持自动重连和重试 - Priority 为 0 的节点永远不参选，但
rs.stepDown()不能在它上面运行——它根本不是 Primary
真正难的不是敲命令，而是判断哪个节点“够格”参选：数据是否同步、心跳是否正常、配置是否一致。别只盯着 rs.stepDown() 成功与否，先看 rs.status().members[n].stateStr 和 .optimeDate。
