数据迁移最佳实践：不停机柔性迁移的SCN接力与双轨并行

大家好，我是数据库小学妹 👋我踩过的坑，你别再踩。

做数据迁移，我最怕在评审会上听到这一句：这套系统 7×24 跑，一秒都不能停，你们方案里那个"停机窗口"，我这里批不出来。

说这话的甲方技术负责人，那次评审把我拉到一边，当面跟我讲的。他就这一句，直接把我方案否了——这套库好几个 T，光全量搬一遍就得大半天，可业务一秒都不能停。这库，到底怎么迁？

卡住我的，其实不是"怎么搬得快"，是"怎么把搬迁从业务时间里挪出去"。历史存量在后台慢慢搬，增量实时追上去，业务全程照跑。今天就聊聊这套"接力"怎么搭起来：数据迁移，怎么才能业务不停机。

一、先给结论：数据迁移想不停机，靠的是"两段接力"

先用一句话说清。不停机迁移，也叫在线迁移、柔性迁移。它的核心是：源库不停写的前提下，先把历史存量搬到新库，再让新产生的增量实时追上去，最后把业务切过去，全程业务不中断。 停机迁移赌的是"窗口够长"，不停机迁移赌的是"同步够准"。这两者的差别，一张表就能看明白。

二、停机窗口这一关，数据迁移越大的库越算不过来

先算一笔账。停机迁移要的窗口，约等于三项相加：全量搬迁时间、校验时间，再加一段回退缓冲。全量时间怎么估？拿数据量除同步速率。现在并行迁移工具跑得越来越快，全量速率能到每小时几百 GB。但就算这么算，2TB 的库全量搬一遍也要好几个小时。实测通常还要打折，时间只会更长。再加校验、加缓冲，窗口得按一整天来报。可核心系统能批多久？常见答复是半小时到几小时。批不出来，方案就卡在第一步，动都动不了。

刚做这行时，我也劝过业务方"就停一晚"。对面是在线交易系统，一晚都停不起。停服迁移省的是技术上的麻烦，风险却全压在业务身上。库小、窗口宽裕，停一下确实干脆；可核心系统，这道关就是过不去。只要你的方案还依赖停机窗口，你就是在赌，赌一个你自己控制不了的东西。更稳的走法，是不去赌窗口，把搬迁从业务时间里挪出去。

三、核心机制：一根"接力棒"，同时接住存量和增量

这是全文的骨架。不停机迁移的核心，是一根"接力棒"，它其实是一个一致性数据位点。Oracle 里叫 SCN，MySQL 里对应 binlog 的位点。把这根棒想成接力赛的交接棒：存量是一棒，增量是另一棒，交接点就是它。

整个动作分四步。一是取棒：在源库上取一个一致性锚点。从这个点往后，源库产生的每一笔变更都得有人接着。二是存量棒：把锚点之前的历史数据搬到新库。这一棒可以慢慢跑，因为它不占用业务时间。干活的是全量迁移工具，比如 KDTS。三是增量棒：从锚点开始解析源库日志。把新产生的增删改实时送到新库。干活的是日志解析类的同步工具，比如 KFS。四是交棒：增量追平、校验一致后，把应用连接切到新库。这一棒只要几秒到几分钟。

关键就一句话：存量搬完的那一刻，增量正好从这个点接上，不漏也不重。 取锚点的动作，在源库上就这么两行。

-- 在源库（Oracle）上取一个一致性锚点
SQL> alter system checkpoint global;
SQL> select checkpoint_change# from v$database;
-- 假设取到 SCN = 200725471，这就是那根"接力棒"

拿到锚点，增量就从它开始追。

# 源端 KFS 从接力棒这个点开始，解析之后的日志
fsrepctl -service oracle online -from-event ora:200725471:200725471
# 目标端 KFS 启动，把增量追平到金仓
fsrepctl -service kingbase online

这里还有个更取巧的做法：干脆连"取棒"都不碰生产库。加一台中间库，用生产库做一次 RMAN 全量备份，同时记下 SCN。把备份在中间库上还原，再用迁移工具把历史数据从中间库搬过去。这时的搬迁时间完全不受限，因为中间库跟业务没关系。另一边，从生产库那个 SCN 开始解析 redo 日志，把搬迁期间的新增变更追平。生产库几乎零压力，应用和原有数据库都不用改。难点被拆成了两块互不干扰的活，金仓的柔性迁移方案走的就是这一路。

四、增量为什么走"日志解析"，而不是触发器加中间表

增量的做法有两条路，差别很大。老办法是触发器加中间表：在源表上挂触发器，表一变就把主键写进一张中间表。再写个程序不停扫中间表，把变化的记录同步出去。这套能用，但代价落在源库身上。高并发写入的表挂上触发器，每次写入都多一笔写中间表的开销，源库压力直接上去。触发器逻辑还得跟着业务维护，库一升级就可能失效。

另一条路是物理日志解析，代表就是 KFS（Kingbase FlySync）这类异构数据同步工具。数据库本来就会把每一次变更记进日志。Oracle 记在 redo log，MySQL 记在 binlog。这类工具直接解析日志，把变更捞出来。好处很直接。它不动源库的表结构，不加触发器，不建中间表。 对业务基本无侵入。日志本来就要写，解析它只是多了一个读取方。而因为是按事务日志解析，事务的边界和提交顺序都能还原。端到端的事务级一致性，也就有了保障。

这也解释了，为什么医疗、金融这类核心系统，更愿意用日志解析做增量。源库是生产的命门，谁都怕往上加东西。

五、切过去，还得能切回来：双轨并行与灰度割接

割接这一步，风险最集中，我的原则只有一条：切慢一点没关系，退路一定要留好。 双轨并行分两个阶段。阶段一，原系统是主，新库是备。KFS 把数据变更实时同步到新库。业务还在原系统跑，新库先分担一些查询。这相当于影子运行，不改变原有拓扑，风险低。阶段二，新库转为主，原系统转为备。这次反过来，把新库的变更同步回原系统。万一新环境出故障，原系统能迅速接管。

切流也不会一次全切，核心业务走灰度：先把 10% 到 30% 的非核心流量切到新库。跑几天看延迟和错误率，稳了再全量切。这段并行期需要双向同步。切过去的业务在新库产生的变更，得同步回原库。两边数据始终一致，用户完全无感知。回退方案要提前写死：判断依据是什么、谁有权启动回切、回退窗口多长，都得在演练里验过。

压测这块，我以前也迷信自己写的脚本，觉得测得够全，就不用再回放生产负载了。复盘时我才回过味：人手写的脚本，边界场景一个都盖不住。有个负载回放工具叫 KReplay，能把生产环境一段时间的真实负载抓下来，在测试环境原样重放。脚本压不出来的差异，也就提前暴露在上线之前。

六、搬完了怎么证明搬对了：数据迁移的校验，一步都不能省

到校验这一步，很多团队就开始赶工期了。常见做法是抽样比对，抽几千行，对得上，就算过。抽样有个绕不开的问题：它永远抽不到边界值，而差异往往就藏在边界上。我见过一次，一张看着简单的字典表，排序规则跟原库不一样。抽样几百行都对得上，一上全量比对就露馅了。从那以后我改了做法。校验范围由业务方和 DBA 一起定，不接受"这张表简单，跳过吧"。

再说校验的方式。老做法是全表比对，库一大，动辄几个小时，还占资源。另一个路子是"增量校验"，KFS Ultra 这类工具就是这么做的。源端解析事务日志，把指定时间内发生变化的数据捞出来，放进内存哈希表。再按主键到目标库把对应记录查出来比对。只比"变过的数据"，不用全表扫。这套方案的效果，金仓公开资料里给过一组数。在一个存量 4T+、日增 50G+ 的核心系统里，一致性校验从"全量 6 小时以上"压到"增量 10 分钟以内"。校验时，业务机的 CPU 负载增加不到 3%。校验这件事，第一次不用拿整个业务窗口去换。

七、案例复盘 + 决策框架

拿一个公开的柔性迁移场景，把上面几步串一遍。源库是 Oracle，目标库是 KES。先加一台 Oracle 中间库，用生产库做一次 RMAN 全量备份，同时记下 SCN。在中间库上还原这份备份，再用 KDTS 把历史存量搬到 KES。时间不受限，生产库没压力。同时启动 KFS，从生产库那个 SCN 开始解析 redo 日志，追平中间库搬迁期间产生的新增量。增量追平后，业务连接切到 KES。全程业务不停，应用和原有数据库都不用改。

再看收益落在哪。金仓官网公开过一个运营商案例。海南移动的 O 域核心故障管理系统，近 10TB 数据，要求小时级完成迁移、业务全程不能中断。他们用 KFS 做在线同步、KDTS 搬存量，最后整库平移、业务无感知。这类案例真正的门道，都落在**“占用业务时间的那部分被压到了多小”**上，跟工具跑得多快关系不大。那问题来了，你的库该不该上不停机迁移？先看这张表。

也得说清它的代价，别只讲好处。不停机迁移链路更复杂，要多一套同步工具、多一份运维。回退要提前演练，切换期还得有人值守。这几年信创替换铺开，越来越多核心系统要从 Oracle、MySQL 迁到国产库。"业务不能停"几乎成了硬约束。但库小、窗口宽裕的项目，停服迁移反而更干脆。别为了显得"高级"去上不停机，要用在窗口真批不出来的地方。

八、数据迁移避坑清单

坑踩得多了，真正要命的就这三条。取 SCN 和做备份，得在同一个时刻。 差一点，存量和增量之间就会漏一段、或重一段。我见过有人备份做完半小时后才去取 SCN，那半小时的变更，就悄悄丢了。

大表别硬搬，拆开并行跑。 一块一块搬，比单线程快得多，也更好控，断了还能接着来。

双轨期，老库别急着下线。 观察窗口留足，覆盖一个完整业务周期。月末、季末这种时点，最容易出问题。

写在最后

所以数据迁移想不停机，说到底就一条路：**别跟停机窗口硬碰，把迁移拆成"存量 + 增量"两段接力。**一根 SCN 接力棒接住两头，双轨并行切流，随时能退回来。

这几步拆开看都不新鲜：存量在后台慢慢搬，增量靠日志实时追，割接留好退路，校验别省钱。可正是它们，"业务不能停"这句要求才站得住。这几年国产库的迁移工具链成熟了不少，把这几步攒成了一条能照着走的流程，金仓是走得比较早的那一批。我一直觉得，好的迁移方案未必技术多炫，能让业务感觉不到你在搬家就够了。

你们那边的系统做迁移时，停机窗口一般能批多久？欢迎在评论区聊聊。我也想知道，你们是怎么跟业务方"讨价还价"的。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋