MongoDB 迁移不停机落地实践：实时迁移方案与切换详解

数据库迁移，最怕的就是「迁移期间业务不能停」。最近一个做游戏业务的朋友就遇到这个难题：自建 MongoDB 要迁到云托管集群，但老板要求迁移期间游戏不能停服。

这类需求在云迁移场景里非常典型。本文按实战顺序，把「不停机迁移」的关键点捋清楚：实时迁移的 pull/push 怎么选、切换窗口怎么卡、迁移完怎么验、回滚怎么退——补全工具文档里一笔带过的部分。

一、先分清：你要的是哪种 MongoDB 迁移

「MongoDB 迁移」至少指向四种不同的场景：

1. 自建 → 云托管：源端自管 MongoDB，目标端是云托管集群（Atlas、腾讯云数据库 MongoDB 等），要近零停机。
2. 云 → 云 / 云 → 自建：跨环境搬迁，工具反向使用。
3. MongoDB → MongoDB 集群间：一次性搬完或持续同步，用 mongosync。
4. 关系型 → MongoDB / MongoDB → 国产库：异构迁移，走异构 CDC 工具或国产数据库工具。

四种场景的目标、工具、停机容忍度都不一样。这张表先把地图摊开：

一句话：今天要「不停机迁上云」，主力就是第一行的「实时迁移」，后面的是备选和异构场景的补充。

二、实时迁移——最被低估的不停机方案

实时迁移（Live Migration）把流程拆成两段：

1. 全量 + 增量同步阶段：目标端从源集群持续拉数据，边拉全量边追增量。
2. 切换（cutover）阶段：数据追平后，主节点角色切过去，业务改连新库。

这里有个反复强调、但容易忽略的前提：

实时迁移要求源集群必须保持在线。因为迁移过程会先迁从节点、最后切换主节点；源集群已经停机的话，没法完成「先迁从、后切主」的动作。

翻译过来就是：实时迁移能省停机时间，但救不了「已经挂了」的库。库已停机的，走备份恢复。

三、pull 和 push 到底差在哪

实时迁移下有 pull（拉取）和 push（推送）两种模式：

选型一句话：看源库网络是「能进」还是「只能出」。内网机房、有防火墙、只能单向出网的老系统，push 往往更顺；公网或云上的源库，pull 更省事。

反常识的一点：「实时迁移」不等于「零停机」。它只是把停机窗口从「小时级」压到「分钟级」。真正零停机要靠应用层双写或读写分离切流。

四、mongosync / mongodump+restore——「搬一次」的自助姿势

不是所有迁移都值得上实时迁移。目标端不是云托管、或者只是「搬一次就完事」的，用自助工具更省心。

• mongosync：官方集群间同步工具，先全量后增量，能追到源端位点再切，适合 Mongo → Mongo 的集群搬迁。
• mongodump + mongorestore：经典的自助方案，本质是备份 + 恢复。缺点是停机窗口明确，数据量大时耗时明显。

三者（实时迁移 / mongosync / mongorestore）的结论对比：

• 近零停机 + 目标端是云托管 → 实时迁移；
• 集群间同步、能接受分钟级切换 → mongosync；
• 简单可控、能接受停机窗口 → mongodump/mongorestore；
• 一致性：三者都能最终一致，但断点续传能力不同——mongosync 和实时迁移按位点续传，mongorestore 断了基本要重来；
• 双向同步：三者都不是双向同步工具，双向是 CDC 的活。

五、异构迁移——MongoDB → 国产库 / 关系型库

目标端不是 Mongo 生态（国产库、Oracle、数仓）时，走异构 CDC 或云厂商 DTS，以及专业 CDC 工具（如金仓 KFS）。这类工具挂在源库上解析 oplog，把变化实时翻译成目标端语句，具备秒级延迟、按位点断点续传、在线数据比对等能力。

判定就一条：目标端是不是 Mongo 生态。是，走前四条；不是，走异构 CDC / DTS。

六、不停机的真正前提，是这三件事

工具选对只是第一步，翻车点常在工具之外：

1. 源库版本兼容性：实时迁移对源集群版本有要求。动手前先核对源版本是否在支持矩阵内，老旧版本往往要先原地升级。
2. 写入流量怎么扛：迁移是「边搬存量、边追增量」。高并发写入下增量追不完，切换窗口就一直关不上。要么选低峰期，要么先限流/降级部分写。
3. 带宽与跨区域延迟：跨云、跨地域迁，网络是隐性成本。先估全量数据量 ÷ 带宽 = 全量搬运时间，再叠加增量速率，才算得出真实切换窗口。

这三件事，是「能不能不停机」的真正决定因素。

七、切换窗口怎么卡：一段能抄的流程

数据追平之后，切换五步：

1. 停写（或只读）：业务切到只读或暂停写入，制造静止点。
2. 确认追平：核对源/目标两侧文档数、最新 oplog 位点。
3. 切主：目标端完成 cutover，或把同步任务标记完成。
4. 改连接串：应用层把连接地址切到新库（这一步最容易漏，写进变更工单）。
5. 观察窗口：切换后留一段观察期，看新库读写延迟、报错、连接数。

切换窗口的目标不是「快」，而是「可回退」。

八、回滚方案：别等切挂了才想

迁移前就写好回滚方案：

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

九、迁移后验证：别用「感觉」验收

验收四件套：

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

能过这四关，才允许删旧库。

十、踩坑清单 + 速查表

「不停机迁上云」的高频踩坑点：

1. 增量追不完、窗口关不上：高并发写 + 小带宽。→ 选低峰 + 先限流。
2. 版本不兼容才发现：迁到一半报「源版本不支持」。→ 动工前先核支持矩阵。
3. 切主后忘了改连接串：新库白迁，业务还打在旧库上。→ 连接串写进变更单。
4. 旧库删太快：回退无门。→ 旧库保留观察期。
5. 没验索引：行数对了，查询慢到爆。→ 索引也进验收清单。
6. 跨区域带宽没算：全量迁了两天还没完。→ 先估全量时间再定窗口。

十一、行动 Checklist

• 确定迁移方向，选对工具
• 核对源库版本是否在支持矩阵内
• 判断网络方向，定 pull 还是 push
• 估算全量时间 = 数据量 ÷ 带宽
• 选低峰期 + 预留写入限流方案
• 写好切换五步流程（含连接串切换）
• 提前定回滚方案，旧库保留观察期
• 准备验收四件套

MongoDB 迁移上云不停机，难的不是工具，是把「版本、带宽、切换、回滚」这四件事提前想清楚。

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