如何升级MongoDB副本集中的硬件配置_热替换节点的数据平滑迁移-MongoDB-PHP中文网

热替换副本集节点前必须确认：1. secondary同步延迟≤10分钟；2. oplog覆盖时长≥24小时；3. 待替换节点_id与新节点完全一致，否则视为新增成员引发投票异常。

如何升级mongodb副本集中的硬件配置_热替换节点的数据平滑迁移

热替换节点不是“换完就完事”，MongoDB 副本集会拒绝不满足条件的成员变更。最常卡住的是 rs.status() 中某个节点长期处于 STARTUP2 或 RECOVERING 状态，本质是同步没跟上或 oplog 不够长。

用 rs.printSecondaryReplicationInfo() 检查所有 secondary 的同步延迟（syncedTo 时间差），确保最大延迟 ≤ 10 分钟；否则新节点可能因 oplog 截断无法完整同步
确认 oplogSizeMB 足够：用 db.getReplicationInfo() 查看当前 oplog 覆盖时长，建议 ≥ 24 小时（尤其写入密集场景）
检查 rs.conf() 中待替换节点的 _id 和 host 字段——新节点必须用**完全相同的 _id**，否则副本集会当作新增成员而非替换，引发投票数异常

不能直接删旧加新，必须通过重载配置实现平滑过渡。核心是让新节点先以 hidden + priority 0 加入，等数据追平再切换角色。

在新机器上启动 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.reconfig() 替换原节点配置：把旧 host 改成新地址，保留 _id、priority、votes 等所有字段
**关键动作**：替换后立刻执行 rs.stepDown() 让 primary 交棒，触发一次完整选举，验证新节点能否正常参与投票

直接删旧加新看似简单，但会触发两次选举（删节点一次、加节点一次），且新节点加入时默认 priority=1，可能意外抢主，造成写入中断。

删节点瞬间，副本集多数派可能不满足（如 3 节点删 1 个，剩余 2 个，但需要 ⌊n/2⌋+1 = 2 票——刚好卡在临界点，primary 会主动 stepDown）
新节点加入后从 initial sync 开始，期间占用大量磁盘 IO 和网络带宽，可能拖慢其他 secondary 的同步速度
如果旧节点还残留 .lock 文件或未 clean shutdown，新节点尝试连接时会报错 Failed to connect to XXX: No such file or directory，实际是系统级连接被拒，不是 MongoDB 配置问题

新机器 CPU/内存/磁盘换了，但 MongoDB 不会自动适配，有些参数得手动对齐，否则性能反而下降。

核对 /proc/sys/vm/swappiness：生产环境应设为 1（而非默认 60），避免 mongod 进程被 swap，否则 WT_CACHE_FULL 错误频发
检查 storage.wiredTiger.engineConfig.cacheSizeGB：新机器内存翻倍了，但配置没改，WiredTiger 缓存仍用旧值，大量读会击穿缓存直落磁盘
验证 net.maxIncomingConnections 是否足够：万兆网卡 + 高并发下，旧值（如 65536）可能成为瓶颈，新节点需按公式 max(65536, 连接数峰值 × 1.2) 调整

MongoDB 副本集热替换真正难的不是操作步骤，而是判断“什么时候算准备好”——oplog 时长、同步延迟、配置字段一致性，这三个点任何一个没盯住，后续就容易出现 silent 数据不一致。