天日可人1. 为什么“凌晨两点停机迁移”越来越行不通了
先聊个实际场景。早些年做数据库迁移，最稳妥的方案就是停机窗口：凌晨两点，挂公告，停服，导数据，校验，切流量，开盘。一套流程走下来，运气好四五个小时，运气不好直接拖到天亮，运维和研发一起在机房里熬红眼。
这套做法在今天正变得越来越尴尬。业务对可用性的要求已经不是“99.9%”这种口号了，而是实打实的考核指标。你凌晨停服四个小时，SLA 直接触线，老板半夜看到监控告警电话就过来了。更麻烦的是，现在的系统架构普遍是微服务化、多活部署，数据库之间还有实时同步链路，你停掉一个核心库，上下游全部阻塞，恢复起来根本不是“把服务拉起来”那么简单。
所谓“不停机数据迁移”，翻译成人话就是：在业务完全不中断、用户无感知的前提下，把数据从旧存储完整搬迁到新存储，并且保证迁移过程中写入不丢、查询不脏、切换瞬间无缝。这事听起来简单，做起来动辄涉及几十张表、上亿行数据、多个消费者链路，任何一个环节没考虑周全，都可能变成线上事故。
这篇内容我会从方案选型、架构设计、搬迁执行、校验兜底、踩坑复盘这几个维度，把不停机迁移的完整链路拆开讲。适合正在准备做存储迁移的同学参考，也适合已经踩过坑、想回头对照一下自己哪里做漏了的同行。
需要先说明一点：不同业务的数据量级、一致性要求、写入模型差异很大，没有一套配置能通吃所有场景。我这里给出的经验和方案是基于通用实践的合理补充，你在落地时一定要结合自己的业务形态做裁剪。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 迁移方案选型：先搞清你面对的是哪种“不停机”
不停机迁移不是一种技术，而是一类技术方案的统称。选哪个方案，取决于一个核心变量：旧库和新库之间是否需要在迁移期间保持双向写入。
2.1 一次性搬迁 vs. 增量同步，两者的适用边界
如果你的场景是数据量不大（比如千万行以内）、业务允许短时间只读（比如内部管理系统），那“先全量导出——导入新库——校验——切读流量——放开写流量”这种简化版流程就够了，其实算不上严格的“不停机”，顶多是“短停写、不停读”。
但真正的线上核心业务（订单、支付、用户、库存）几乎都是持续写入的，停写哪怕一分钟，都会产生数据空洞。这时候就需要引入增量同步机制：全量迁移老数据的同时，把新产生的变更实时或准实时地同步到新库，等两边数据追平之后，再找一个流量低点完成切换。
我见过不少团队在这个环节走了弯路：一上来就想着“直接用同步工具全量导”，结果忘了业务还在写，数据导到一半，老库新增的数据根本没有同步过去，切换一发生，用户已下的订单直接消失。这不是工具问题，是方案设计问题——你必须先想清楚，迁移期间老库继续写入这件事，怎么处理。
2.2 CDC（变更数据捕获）为什么是当前主流选择
不停机迁移的增量同步环节，主流做法是 CDC（Change Data Capture）。它的核心思路是：监听数据库的 binlog（MySQL）或 WAL（PostgreSQL），把每一次 insert、update、delete 操作解析成结构化事件，再投递到新库执行，从而保证新库能“重放”老库发生的所有变更。
相比起业务代码双写、定时任务扫表对比这类方案，CDC 的优势很明显：
- 对业务代码零侵入，不需要修改现有写入逻辑；
- 捕获的是数据库底层的真实变更，不存在漏写