MongoDB 迁移上线保障实践：切流、回滚与数据校验

凌晨两点，盯着屏幕上的迁移进度条，业务方发来消息：「切了吗？什么时候能切？」

那一刻真正要想的是另一件事：切过去容易，切坏了怎么退？

「MongoDB 迁移」这件事，真正让人睡不着觉的从来不是「怎么搬数据」，而是搬完之后的那几步——停机窗口怎么卡、切流怎么切、切坏了怎么回滚、数据对不对怎么验。这几步，工具教程不讲，官方文档一笔带过，但翻车全在这里。

本文专攻切流、回滚、校验这三件上线前必须想清楚的事。

一、迁移前：先把评估做扎实

动数据之前，先把这四件事算清楚：

1. 数据量：各集合的文档数、数据体积，决定全量搬运时间。
2. 停机窗口：业务能容忍多久不可写？这是后面所有决策的锚点。
3. 网络带宽：数据量 ÷ 带宽 = 全量搬运时间的下限。
4. 目标集群规格：目标端 IO/内存/连接数能不能扛住切流后的真实读写。
5. 目标库类型：是「MongoDB → MongoDB」的同构迁移，还是「MongoDB → 国产库」的异构迁移？如果是信创项目、目标端要落到金仓数据库 KingbaseES 这类国产库，评估里还得加两项——文档模型适配深度、异构增量同步工具（国产生态里金仓数据库的 KFS 就干这个）。

常见翻车：迁移顺顺利利，切流后新库连接数被打满，业务全线超时——因为只算了数据量，没算切流后的读写规格。

二、停机窗口怎么算

不停机是理想，现实是「尽量短的停机窗口」。窗口构成就三块：

停机窗口 ≈ 增量追平时长 + 切换动作时长 + 观察缓冲

• 增量追平时长：全量搬完后，追上「搬运期间新产生的写」需要多久。写入越猛、带宽越小，这段越长。
• 切换动作时长：停写 → 确认追平 → 切主 → 改连接串，几分钟到几十分钟。
• 观察缓冲：切完后留一段观察期，别急着下结论。

能压缩的只有「增量追平」这一段：选业务低峰、先限流部分非核心写，给增量一个追平的机会。

三、增量同步怎么追：全量 + 增量两段式

一次靠谱的 MongoDB 迁移，几乎都是「全量 + 增量」两段式：

1. 全量阶段：把存量数据一次性搬过去（dump/restore、mongosync、实时迁移都在干这个）。
2. 增量阶段：全量期间新产生的写，靠 oplog 位点持续追。源端记着「搬到哪个位点」，目标端从那个位点接着追。

判断追平的金标准：源端最新 oplog 位点 ≈ 目标端已应用的位点，且落后不再扩大。别只看「任务状态显示完成」，要看位点。

四、切流五步：一段能抄的流程

数据追平后，切流按这五步走：

1. 停写（或转只读）：业务切到只读或暂停写入，制造静止点。
2. 确认追平：核对源/目标文档数、最新位点一致。
3. 执行切换：实时迁移做 cutover，或停掉同步任务、标记完成。
4. 改连接串：应用把连接地址切到新库（这一步最常漏，写进变更工单）。
5. 观察期：盯新库的读写延迟、报错、连接数，留一段缓冲再收工。

切流的目标不是「快」，是「每一步都留着退路」。

五、回滚方案：切之前就写好

最惨的割接：切到新库半小时才发现问题，旧库已经被删，回退无门。回滚方案必须在切流前写好：

• 旧库保留观察期：切成功后旧库至少留 7 天，期间保持同步或快照，别急着删。
• 应用层留双写开关：用配置控制「写旧库/写新库/双写」，一键回退。
• 回退动作：改回旧连接串 → 旧库恢复可写 → 反向追平增量 → 重新切。回退本身也是一次迁移，别当儿戏。

回滚能不能成功，取决于你有没有提前保留旧库和数据位点。

六、迁移后数据校验：别用「感觉」验收

「迁移跑完了」和「迁移跑对了」是两码事。验收四件套：

1. 数文档数：源/目标分别 countDocuments({})，行数对上第一关。
2. 核对索引：getIndexes() 对比两侧索引名、字段、唯一性，索引缺失会让新库慢得明显。
3. 抽样比对：挑关键集合抽几条做字段级哈希比对，行数一样不代表内容一样。
4. 应用连通性：用真实业务连新库跑读写，看报错和延迟。

过不了这四关，就别删旧库。

七、常见报错对照表

八、完整检查清单：上线前过一遍

• 迁移前评估：数据量、停机窗口、带宽、目标规格、目标库类型（同构/异构）
• 全量 + 增量两段式方案已定
• 停机窗口 = 追平时长 + 切换时长 + 缓冲，已测算
• 切流五步流程已写进变更工单（含连接串切换）
• 回滚方案已定：旧库保留、双写开关、回退动作
• 验收四件套已备：文档数/索引/抽样/连通性
• 常见报错对照表已打印，值班能对着查
• 观察期内监控已挂：延迟、报错、连接数

MongoDB 迁移真正难的，不是把数据搬过去，而是切流、回滚、校验这三件事有没有提前想清楚。

本文基于生产环境实战总结，欢迎交流。