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

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

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

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

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

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

| 维度 | 停机迁移 | 不停机迁移（柔性迁移） |
|:---|:---|:---|
| 业务影响 | 停服，窗口内不可用 | 业务全程在线 |
| 前置条件 | 申请到停机窗口 | 拿到一致性 SCN / binlog 位点 |
| 存量数据 | 停机后一次性搬 | 边搬边写，业务照常 |
| 增量数据 | 无 | 从锚点起实时追平 |
| 割接方式 | 一刀切 | 双轨并行 + 灰度切流 |
| 回退能力 | 靠备份回滚，慢 | 反向同步 / 回切，快 |
| 适用场景 | 库小、窗口宽裕 | 7×24 核心系统、窗口批不出来 |

![compare.png](https://developer.qcloudimg.com/http-save/yehe-12362123/0522a00e626ccc44145e2968864d35ae.png)

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

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

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

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

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

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

![relay.png](https://developer.qcloudimg.com/http-save/yehe-12362123/48c297f1b2e2c972789f16a56342849f.png)

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

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

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

```bash
# 源端 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 类工具） |
|:---|:---|:---|
| 对源库侵入 | 高：挂触发器、写中间表 | 低：只读日志 |
| 源库性能影响 | 每次写入多一笔开销 | 基本无额外开销 |
| 事务一致性 | 靠程序自己保证，易漏 | 按日志事务边界还原 |
| 维护成本 | 触发器随库升级易失效 | 不用在源库维护对象 |
| 双向 / 回切 | 实现复杂 | 原生支持双向同步 |

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

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

割接这一步，风险最集中，我的原则只有一条：**切慢一点没关系，退路一定要留好。** 双轨并行分两个阶段。阶段一，原系统是主，新库是备。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 搬存量，最后整库平移、业务无感知。这类案例真正的门道，都落在**"占用业务时间的那部分被压到了多小"**上，跟工具跑得多快关系不大。那问题来了，你的库该不该上不停机迁移？先看这张表。

| 你的情况 | 建议 |
|:---|:---|
| 库大、7×24、窗口批不出来 | 上不停机迁移：搬存量 + 追增量 + 增量校验，三段接力 |
| 库中等、能批到数小时窗口 | 停服迁移即可，更简单、更省事 |
| 数据量大、增量稳定、要求可回退 | 用双轨并行 + 灰度割接 |
| 源库是命门、不许动表结构 | 必须走无侵入的日志解析增量 |

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

## 八、数据迁移避坑清单

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

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

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

## 写在最后

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

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

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

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


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

数据迁移不停机方案：存量增量接力与双轨割接设计

业务7×24不能停，数据迁移怎么做？本文把"不停机迁移"拆成一根SCN接力棒：存量先搬、增量靠日志解析实时追平，双轨并行灰度割接，校验只比变化的数据。讲清每一步的坑与验收标准，全程业务不中断。

数据库

运维

架构设计

不停机数据迁移核心是"存量+增量"两段接力：先取一致性SCN锚点，历史数据后台慢搬，增量实时追平，业务全程在线。用日志解析替代触发器减少源库压力，双轨并行+灰度割接保退路，增量校验提升效率。适用于7×24核心系统，窗口批不出来的场景。

数据迁移

数据同步

代码解释

MySQL

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据迁移不停机方案：存量增量接力与双轨割接设计-腾讯云开发者社区-腾讯云

数据迁移不停机方案：存量增量接力与双轨割接设计

数据迁移不停机方案：存量增量接力与双轨割接设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐