直接替换硬件节点需通过rs.reconfig()实现平滑迁移，否则引发选举抖动等故障；替换前须验证：目标节点状态非STARTUP2/RECOVERING、secondary延迟≤10分钟、oplog覆盖≥24小时、新节点_id与原节点完全一致。
直接替换硬件节点不是“停旧启新”就能完成的，必须通过 rs.reconfig() 重载配置实现角色平滑迁移，否则会触发选举抖动、同步中断甚至写入不可用。
替换前必须验证的 3 个副本集状态
热替换失败最常见的原因是副本集拒绝变更配置，本质是数据同步或元数据不满足安全前提：
-
rs.status()中目标节点长期卡在STARTUP2或RECOVERING状态，说明同步未就绪或 oplog 已截断 - 用
rs.printSecondaryReplicationInfo()查所有 secondary 的最大延迟，必须 ≤ 10 分钟；否则新节点无法从 oplog 追到最新状态 - 执行
db.getReplicationInfo()确认 oplog 覆盖时长 ≥ 24 小时（尤其写入密集场景），低于该值极易因截断导致 initial sync 失败 - 检查
rs.conf()中待替换节点的_id字段——新节点启动时必须使用**完全相同的_id**，否则会被识别为新增成员，破坏投票数（如 3 节点变 4 节点）
用 rs.add() + rs.reconfig() 完成平滑过渡
不能先 rs.remove() 再 rs.add()，这会引发两次选举和 priority 抢主风险。正确路径是“先加后换”：
- 在新机器上启动
mongod，--replSet名称必须与原副本集一致，bindIp和port可不同（但需防火墙放行） - 在 primary 上执行：
rs.add({host: "new-host:27017", _id: X, priority: 0, hidden: true})（X 是原节点的_id） - 等待
rs.status().members[X].stateStr === "SECONDARY"且optimeDate与 primary 接近（差值 - 构造新配置：复制
rs.conf()，仅将该成员的host改为新地址，保留_id、priority、votes、hidden等全部字段 - 执行
rs.reconfig(newConf, {force: true})（force 仅在 primary 不可用时用，正常情况无需）
替换后必须立即验证的两个隐藏动作
配置生效不等于服务稳定，以下两步跳过会导致故障难以定位：
- 立刻执行
rs.stepDown()，强制 primary 交棒，触发一次完整选举，验证新节点能否参与投票并成功当选 - 检查新节点的 CPU/内存是否匹配业务负载——老旧服务器常因 CPU 单核性能不足拖慢同步线程，即使磁盘 IO 充足，
oplog追赶速度仍可能低于写入速率 - 确认新节点系统级无残留：若旧节点曾异常关闭，
/data/mongodb/mongod.lock文件未清理，新节点连接时会报Failed to connect to XXX: No such file or directory，实为系统级 socket 拒绝，非 MongoDB 配置错误
真正决定成败的是 oplog 覆盖时长与同步延迟的交叉校验，而不是配置改得有多快。很多团队卡在 RECOVERING 状态，反复重启 mongod，却没意识到问题出在原集群 oplogSizeMB 设置过小——它不是可选参数，而是热替换的硬性水位线。
