MongoDB 迁上云想不停机？pull 和 push 到底怎么选（踩坑记录）
上周，一个做游戏业务的老哥找我：「数据库现在自建在机房，想迁到云上 Atlas，但老板下了死命令——迁移期间游戏不能停服。」他补了一句：「我把官方文档翻了三遍，越翻越慌，感觉每一步后面都藏着坑。」
这种需求我太熟了。你搜「MongoDB 迁移」，排前面的基本是官方文档——权威是真权威，但它是个「工具目录」和「命令手册」，告诉你有什么，不告诉你怎么选、怎么切、切坏了怎么退。
这篇就把「不停机迁上云」这件事按实战顺序捋一遍。官方文档一笔带过的几个地方——pull 和 push 到底差在哪、切换窗口怎么卡、迁移完怎么验、回滚怎么退——我逐个讲透。
（先声明一句：下面所有结论都有真实生产踩坑背书，不是翻译官方文档。）
一、先分清：你要的是哪种 MongoDB 迁移
一上来别急着找工具。「MongoDB 迁移」这个词，至少指向四种完全不同的活：
- 自建 → 云（Atlas）：源端是自管 MongoDB，目标端是云托管集群，要的是近零停机。
- 云 → 云 / 云 → 自建：跨环境搬迁，工具反过来用。
- MongoDB → MongoDB 集群间复制：一次性搬完或持续同步，用 mongosync。
- 关系型 → MongoDB / MongoDB → 国产库：异构迁移，走 Relational Migrator 或异构 CDC 工具。
四种活的目标、工具、停机容忍度都不一样。官方文档最大的问题是把四种混在一个页面里，让你自己猜。这张表先给你把地图摊开：
| 迁移方向 | 官方推荐入口 | 是否近零停机 | 一句话定位 |
|---|---|---|---|
| 自建 Mongo → Atlas | 实时迁移（live migration） | 是 | 源库在线，Atlas 引导式搬运 |
| 集群间一次性/持续同步 | mongosync | 视配置 | 官方集群同步工具 |
| 备份/快照式搬运 | mongodump + mongorestore | 否（有窗口） | 经典备份恢复式迁移 |
| 关系型 → MongoDB | Relational Migrator | 否（快照） | 智能建模 + 数据转换 |
| Mongo → 国产/关系型库 | 异构 CDC 工具（如金仓数据库 KFS） | 是 | 日志级实时同步 |
一句话：今天你要「不停机迁上云」，主力工具就是第一行的「实时迁移」，后面的是备选和异构场景的补充。
二、实时迁移——官方最被低估的不停机方案
Atlas 的实时迁移（Live Migration），是唯一一个「Atlas 帮你干活、你只做确认」的方案。它把流程拆成两段：
- 全量 + 增量同步阶段：Atlas 从源集群持续拉数据，边拉全量边追增量。
- 切换（cutover）阶段：数据追平后，Atlas 把主节点角色切过去，业务改连新库。
这里有个官方文档反复强调、但很多人当耳旁风的前提：
实时迁移要求源集群必须保持在线。因为 Atlas 会先迁移从节点、最后切换主节点；如果你的源集群已经停机，它没法完成「先迁从、后切主」的动作。
翻译成人话就是：实时迁移能帮你省停机时间，但它救不了「已经挂了」的库。库已经停机的，老老实实走备份恢复。
三、pull 和 push 到底差在哪
实时迁移下又有两种模式，pull（拉取）和 push（推送）。官方文档只给了名词，我来给差异：
| 维度 | pull（拉取） | push（推送） |
|---|---|---|
| 谁主动 | Atlas 从源集群「抽」数据 | 源侧（Cloud Manager 监控集群）向 Atlas「推」数据 |
| 源集群出网方向 | 需要能被 Atlas 访问到 | 源侧主动发起，网络方向相反 |
| 适用场景 | 源库网络可被外部访问 / 云上源 | 源库在隔离内网、只能出不能进 |
| 切换对业务影响 | 切到 Atlas 后源库转只读，需停写一小段 | 类似，切换窗口同样要锁写 |
选型就一句话：看你的源库网络是「能进」还是「只能出」。内网机房、有防火墙、只能单向出网的老系统，push 往往更顺；公网或云上的源库，pull 更省事。
反常识的一点：「实时迁移」不等于「零停机」。它只是把停机窗口从「小时级」压到「分钟级」。真正零停机要靠应用层双写或读写分离切流，那是另一个工程话题。
四、mongosync / mongodump+restore——「搬一次」的自助姿势
不是所有迁移都值得上实时迁移。目标端不是 Atlas、或者只是「搬一次就完事」的，用自助工具更省心。
- mongosync：官方集群间同步工具，先全量后增量，能追到源端位点再切，适合 Mongo → Mongo 的集群搬迁。
- mongodump + mongorestore：最经典的自助方案，本质是备份 + 恢复。缺点是停机窗口明确，数据量大时 dump/restore 本身就很耗时。
这三者（实时迁移 / mongosync / mongorestore）经常被拿来对比，直接给结论：
- 近零停机 + 目标是 Atlas → 实时迁移；
- 集群间同步、能接受分钟级切换 → mongosync；
- 简单可控、能接受停机窗口 → mongodump/mongorestore；
- 一致性：三者都能最终一致，但断点续传能力不同——mongosync 和实时迁移按位点续传，mongorestore 断了基本要重来；
- 双向同步：三者都不是双向同步工具，双向那是 CDC 的活。
五、异构迁移——MongoDB → 国产库 / 关系型库
目标不是 MongoDB，而是国产库、关系型库、数仓，前面几条路都使不上劲。这条路我写过一篇《MongoDB 数据同步怎么做？oplog、Change Streams、同步工具 4 种方案一次讲清》，结论先放在这：
- Change Streams：官方 API，但要自己写消费者、自己管断点，适合有开发资源；
- 异构 CDC 工具（我在信创项目里接触较多的是金仓数据库的 KFS）：挂在源库上解析 oplog，实时捕获变化翻译成目标端语句，秒级延迟、按位点断点续传、内置在线数据比对。
判定就一条：目标端是不是 Mongo 生态。是，走前四条；不是，走异构 CDC。
六、不停机的真正前提，是这三件事
工具选对只是第一步。翻车点都在工具之外：
- 源库版本兼容性：实时迁移对源集群版本有要求。动手前先去 Atlas 官方文档核对源版本是否在支持矩阵内，老旧版本往往要先原地升级。
- 写入流量怎么扛：迁移是「边搬存量、边追增量」。高并发写入下增量永远追不完，切换窗口就一直关不上。要么选低峰期，要么先限流/降级部分写。
- 带宽与跨区域延迟：跨云、跨地域迁，网络是隐性成本。先估全量数据量 ÷ 带宽 = 全量搬运时间，再叠加增量速率，才算得出真实切换窗口。
这三件事，官方文档几乎不展开，但它们是「能不能不停机」的真正决定因素。
七、切换窗口怎么卡：一段能抄的流程
数据追平之后，真正的技术活才来。切换五步：
- 停写（或只读）：业务切到只读或暂停写入，制造静止点。
- 确认追平：核对源/目标两侧文档数、最新 oplog 位点。
- 切主：Atlas 侧完成 cutover，或把同步任务标记完成。
- 改连接串：应用层把连接地址切到新库（这一步最容易漏，写进变更工单）。
- 观察窗口：切换后留一段观察期，看新库读写延迟、报错、连接数。
切换窗口的目标不是「快」，而是「可回退」。
八、回滚方案：别等切挂了才想
我见过最惨的一次割接：切到新库后半小时才发现字符集问题，结果旧库已经被删了，回退无门。
所以回滚方案要在迁移前就写好：
- 保留旧库一段观察期：切换成功后旧库至少留 7 天再下线，期间保持同步或快照；
- 应用层留双写开关：切换前后用配置项控制「写旧库/写新库/双写」，一键回退；
- 回退动作：改回旧连接串 → 旧库恢复可写 → 反向追平增量 → 重新切。回退也是一次迁移，别当儿戏。
九、迁移后验证：别用「感觉」验收
验收四件套：
- 数文档数：源/目标分别 countDocuments({})，行数对上第一关。
- 核对索引：getIndexes() 对比两侧索引名、字段、唯一性，索引缺失会让新库慢得你想哭。
- 抽样比对：挑关键集合抽几条做字段级比对，行数一样不代表内容一样。
- 应用连通性：用真实业务连新库跑一遍读写，看报错和延迟。
能过这四关，才允许删旧库。
十、踩坑清单 + 速查表
这些年我在「不停机迁上云」上栽过的跟头：
- 增量追不完、窗口关不上：高并发写 + 小带宽。→ 选低峰 + 先限流。
- 版本不兼容才发现：迁到一半报「源版本不支持」。→ 动工前先核支持矩阵。
- 切主后忘了改连接串：新库白迁，业务还打在旧库上。→ 连接串写进变更单。
- 旧库删太快：回退无门。→ 旧库保留观察期。
- 没验索引：行数对了，查询慢到爆。→ 索引也进验收清单。
- 跨区域带宽没算：全量迁了两天还没完。→ 先估全量时间再定窗口。
| 现象/信号 | 大概原因 | 先查什么 |
|---|---|---|
| 增量永远追不平 | 写入速率 > 同步速率 | 源库写入 QPS、带宽、同步延迟 |
| 报「版本不支持」 | 源库版本过旧 | Atlas 实时迁移支持矩阵 |
| 切完业务全打旧库 | 连接串没切 | 应用配置、DNS/负载均衡 |
| 新库查询极慢 | 索引缺失 | getIndexes() 对比 |
| 全量迟迟搬不完 | 带宽不足 | 数据量 ÷ 带宽估算 |
十一、行动 Checklist
MongoDB 迁上云不停机，难的不是工具，是你有没有把「版本、带宽、切换、回滚」这四件事提前想清楚。
浙公网安备 33010602011771号