rs.reconfig是唯一安全路径，因它原子性替换host字段、保留_id/votes/priority，避免双选举和写入中断；直接rs.remove()+rs.add()会重算投票数与oplog截断点。
直接用 rs.remove() + rs.add() 换节点，90% 会触发双选举、写入中断、新节点同步卡在 STARTUP2 或 RECOVERING ——这不是配置问题，是副本集状态机被强行打断的必然结果。
为什么 rs.reconfig 是唯一安全路径
副本集把每个成员视为带身份（_id）的固定实体，不是“IP+端口”的临时连接。直接删加等于告诉集群：“这个人死了，又来了个新人”，投票数、多数派判定、oplog 截断点全部重算。而 rs.reconfig() 是原子性身份替换：保留原 _id、votes、priority，只换 host 字段，集群感知为“同一个人搬了家”。
- 必须先停掉旧节点（
db.shutdownServer()），避免它和新节点同时以同一_id上线引发冲突 - 新节点启动时，
replSet名称必须完全一致，但bindIp和port可不同（需防火墙放行） - 不能跳过
rs.status()验证：目标节点stateStr必须是SECONDARY，且optimeDate距离 primary 不超过 10 秒（写入不密集时可放宽到 60 秒）
rs.reconfig 执行前必做的三件事
漏掉任意一项，rs.reconfig() 会卡在 “Quorum check failed” 或静默失败。
- 用
telnet new-host 27017从所有存活节点（包括 primary）验证端口连通性——ping通 ≠ MongoDB 可连 - 执行
rs.conf()拿最新配置，检查version字段；新配置的version必须 = 当前值 + 1，term不能降级 - 编辑配置时只改目标成员的
host字段，其他字段（_id、votes、priority、hidden）一个字符都不能动，连空格都不能多
执行 rs.reconfig 后必须立刻验证的两个动作
配置生效不等于服务稳定，真正考验在切换后 30 秒内。
- 立刻在 primary 上执行
rs.stepDown()，强制触发一次完整选举——这是检验新节点能否参与投票、能否被选为 primary 的唯一方式 - 选举完成后，立刻跑
rs.printSecondaryReplicationInfo()，确认所有 secondary 的syncedTo时间差 ≤ 10 分钟；若新节点延迟突增，说明 oplog 不够长，要紧急调大oplogSizeMB
最容易被忽略的是硬件差异本身：新机器 CPU 核数翻倍但内存没跟上，WiredTiger 缓存池（wiredTiger.cacheSizeGB）仍沿用旧配置，会导致大量 page fault 和磁盘 IO 暴涨——这和 rs.reconfig 无关，但会让整个迁移后的性能表现远低于预期。
