

前几天遇到个问题，我觉得值得写下来分享一下。

手上有个活儿前后干了快两个月：一个 2.4TB 的订单库从 Oracle 迁到国产数据库，业务不能停，只给了一个周末的割接窗口。

方案先定下来了：全量打底，增量追平，最后割。评审会上有个开发问我：「为什么不直接上增量同步？增量多快啊。」

问题问得不糙。细究下去，它牵出来的东西不少——什么时候必须全量、全量怎么并行、增量从哪个位点起、割接前那几分钟怎么保证不漏数据。这篇一次讲完：全量与增量是什么关系、什么时候用哪个，以及这次在几个数据库上我实际怎么配。做迁移和容灾的同行，可以直接拿去对位。

## 一、先把两个词捋顺

歧义主要在「同步」这个动作上。很多人脑子里，同步就是一种持续跑的状态，那增量确实显得比全量「高级」。换个角度看就清楚了：全量同步是在某个时刻，把源库此刻的全貌拷一份到目标库；增量同步是从某个时刻起，把源库后续产生的变化一条不落地重放到目标库。

一个是截面，一个是流。这两个概念分清，后面的判断就都有依据。

## 二、什么时候必须全量，什么时候增量就够了

实际项目里的判断整理成一张图，对着自己的场景看就行。

![image.png](https://developer.qcloudimg.com/http-save/yehe-11922820/305b2d6359fbcc9baf5ee2162dc11b42.png)

拆开说四类场景。

**1. 目标库是空的，或者要重建。**

这一条没有讨论空间。源库 2TB，增量日志里只有变化量，历史数据不会凭空出现，必须先把存量搬过去。这就是全量的位置——它的作用不是「快」，是「打底」。

**2. 历史上没有可用的同步位点。**

增量有个硬前提：得知道从哪儿开始。要么有一条持续的归档/日志链路没断过，要么有一个明确的 SCN/LSN 记录点。很多系统迁移前压根没留下这些东西，你说增量，从哪增？只能先全量，再从全量结束的那个位点开始增量，这个位点才有意义。

**3. 源端在迁移前发生过结构变更或数据清洗。**

这种情况下历史日志重放过来，会把这些变更再「重放」一遍，反而搞出不一致。要么在日志层面过滤，要么干一次全量重新对齐。我倾向后者，省事，也少一层不确定性。

**4. 数据量小、可停机。**

几千张表里就几十张核心小表，或者业务允许停机两小时。这种活儿别上 CDC，mysqldump / sys_dump / expdp 导一遍，比搭一套增量链路靠谱得多。技术复杂度要和业务收益对上，不是越复杂越专业。

增量真正不可替代的场景只有一个：业务不能停，数据量又大到全量撑不住窗口。这时候唯一的办法是「全量打底 + 增量追尾」，用全量解决历史，用增量解决割接窗口里那段时间的写入。

所以那两个词不冲突。

## 三、全量阶段：慢的不是数据量，是做法

见过最典型的错误做法，是拿一把单线程的导数据工具跑 2TB，进度条上剩余时间显示「约 3 天」，然后开始怀疑网络、怀疑磁盘、怀疑数据库。

先排掉一个东西：`COUNT(*)`。开工前有人喜欢统计一遍总行数，千万级以下还好，到了亿级就是一次全表扫描，纯粹给自己制造时间压力。数据量看统计信息或者段大小就够。

真正的瓶颈在两处：取数是单线程还是并行，导数是逐行还是批量。

这次用**金仓 KFS** 做全量抽取，核心三个动作：按主键范围切分片、固定并发、走外部表落文件。

```bash
# KFS 全量：按主键范围并行分片导出（示例，版本不同参数名有差异）
kfs_extract -c /etc/kfs/kfs.conf \
  -T ORDER_MAIN \
  --parallel 8 \
  --split-by ORDER_ID \
  --split-size 500000 \
  --consistency snapshot \
  --out /data/kfs/dump/order_main.dat
```

第二个动作决定耗时量级。批量插入一次 1000 条和一条一条插，差距通常在一到两个数量级。这常识听着像废话，但每年都能在别人的迁移脚本里看到 `INSERT INTO ... VALUES (...);` 一行一条循环跑几百万次。

```sql
-- 目标端批量装载，一次 1000 行，比逐行插入快一个量级
COPY ORDER_MAIN (ORDER_ID, CUST_ID, AMOUNT, STATUS, CREATE_TIME)
FROM '/data/kfs/load/order_main.dat'
WITH (FORMAT csv, DELIMITER '|', NULL '', BATCH_SIZE 1000);
```

对 Oracle 老库，习惯上用 SQL\*Loader，那就把 `BINDSIZE` 和并行参数调足，别拿默认值跑亿级。

还有一件事常被忽略：全量的起点和增量要衔接得上。全量如果只是「开始的时候查了一下」，跑到一半源库还在写，等你跑完，这期间的变化在不在目标库里？不在。所以全量要么在源库挂起写入（业务能停的情况），要么走一致性快照（`AS OF SCN` / 导出事务快照），把「全量那一刻」固定下来。这个快照点就是增量链路要补的起始点。记错了，后面校验对不上，返工一次比全量还贵。

## 四、增量阶段：位点、幂等、延迟

全量跑完，链路切到增量。增量这块出问题，集中在三处。

![image.png](https://developer.qcloudimg.com/http-save/yehe-11922820/a5a13c8a2173f37125200fecc3f45357.png)

**位点。** 金仓 KFS 这套 CDC 以源库的归档日志和 redo 为输入，我在全量开始前就把当前 SCN 记下来了，全量结束后从这个 SCN 拉增量，中间那段写入就能补齐。

```sql
-- 全量开始前记录起始位点，这个值就是增量的起点
SELECT CURRENT_SCN FROM V$DATABASE;
```

**幂等。** CDC 重放最怕重复。链路重启、位点回退、网络抖动重传，都可能让同一条变更被执行两次。目标端没有主键约束的话，结果就是一份数据变两份。所以 CDC 出来的每张表，主键或唯一索引必须先在目标库建好，然后冲突策略要明确：是 `IGNORE`、是 `MERGE`、还是先落中间表再合并。别指望链路永远不重传。

```sql
-- 目标端以主键为锚做 upsert，重放过也不会出双份
MERGE INTO ORDER_MAIN t
USING STG_ORDER_MAIN s
ON (t.ORDER_ID = s.ORDER_ID)
WHEN MATCHED THEN UPDATE SET t.STATUS = s.STATUS, t.AMOUNT = s.AMOUNT
WHEN NOT MATCHED THEN INSERT (ORDER_ID, CUST_ID, AMOUNT, STATUS, CREATE_TIME)
VALUES (s.ORDER_ID, s.CUST_ID, s.AMOUNT, s.STATUS, s.CREATE_TIME);
```

**延迟。** 要盯的不是「有没有延迟」，是延迟的趋势。每秒几万笔写入的库，如果延迟从 200ms 稳步涨到 5s，那不是网络问题，是目标库的写入跟不上，或者某张表缺索引导致每次 apply 都全表扫。每天固定时段延迟暴涨，就去查是不是批量任务在跑。

```sql
-- 观察 CDC 应用延迟，看趋势不看瞬时值
SELECT apply_name, applied_scn,
       (SELECT CURRENT_SCN FROM V$DATABASE) - applied_scn AS scn_gap,
       SYSDATE
FROM v$kfs_apply_status;   -- 视图名以实际版本为准
```

## 五、割接窗口：全量和增量在这里交接

这活儿的时间和大多数人想的不一样。割接窗口只留给增量追尾，不给全量。

这次的做法是：全量提前两周跑，白天跑，跑崩了重来也没关系；这期间增量链路一直挂着追，追不平就查；割接当天业务一停，源库不再有写入，增量链路把最后那点积压吃完，SCN 对齐，切换应用连接。

交割点要有一个明确判据。我用的就一条：

```sql
-- 割接判据：源端与目标端 SCN 差值归零，且稳定保持
-- 源库（割接前只读）
SELECT CURRENT_SCN FROM V$DATABASE;
-- 目标库
SELECT applied_scn FROM v$kfs_apply_status;
-- 两者相等后，再做一轮抽样校验，然后切流
```

差值不为零，不切。差值忽大忽小，说明还有写入在进来，源库没停干净，也不切。这一步不要省，也不要用「看起来差不多了」来判断。

## 六、几个数据库上我实际怎么配的

下面这些都是手上跑过的，写法按各自语法来，改表名和参数就行。

### 金仓 KES + KFS（这次用的）

先说自己这次的主力。KES 主库到 KES 备库的增量，用它自带的基于物理日志的主备复制就够，常规高可用完全够用，延迟低、配置简单，很多场景不用再外挂东西。真正需要独立 CDC 链路的是另外几种：跨库、跨版本，或者要保留原库做双跑对比。

```bash
# KFS 增量：从全量结束的 SCN 起拉归档日志
kfs_sync -c /etc/kfs/kfs.conf \
  --mode incr \
  --start-scn 3487291056 \
  --tables ORDER_MAIN,ORDER_ITEM,CUST_INFO \
  --apply-mode upsert \
  --commit-interval 2000
```

这套组合我比较看重的地方是指标能读：全量进度、增量延迟、同步行数、失败重试，都在一个界面上。同步这事最怕黑盒——跑着不知道到哪了，出问题不知道错在哪。一个能看清进度的工具，和只能看日志的工具，维护成本差得远。

### MySQL 主从（binlog）

MySQL 主从是天然的增量同步，全量一般靠 `mysqldump --single-transaction` 打底，dump 里自带 `CHANGE MASTER TO ... MASTER_LOG_FILE/POS` 的位置，那就是增量起点。这个设计挺好，位点随全量数据一起走，不靠人去记。

```sql
-- 全量：single-transaction 保证一致性快照，不锁表
-- mysqldump --single-transaction --master-data=2 --source-data=2 -A > all.sql
-- 增量：从全量导出的位点开始
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.11',
  SOURCE_LOG_FILE='mysql-bin.000842',
  SOURCE_LOG_POS=1934572,
  SOURCE_AUTO_POSITION=0;
START REPLICA;
```

要注意的是 `binlog_format` 必须是 `ROW`。`STATEMENT` 模式下有些函数在从库重放会算出不同结果，我见过一条 `NOW()` 相关的写入在主从两边时间不一致，查了半天。



### Oracle GoldenGate

Oracle 到国产库的老项目上，GG 用得最多。全量用 initial load（老版本是 `INITIAL LOAD EXTRACT`），增量用 `EXTRACT` + `REPLICAT`。配置里最关键的不是抽取，是 `HANDLECOLLISIONS`——初始装载和增量交叉那段时间，同一条记录可能既被全量插入、又被增量更新，这个参数就是处理这种交叉的。

```
-- GG 增量应用段，处理全量/增量交叉
REPLICAT rord
SOURCECATALOG ORCL
MAP ORCL.ORDER_MAIN, TARGET kes.order_main,
    COLMAP (USEDEFAULTS),
    KEYCOLS (ORDER_ID);
HANDLECOLLISIONS
```

`HANDLECOLLISIONS` 打开能救急，但它本质是「出错就跳过」，会把问题藏起来。割接完成后必须关掉再看一轮，不然你永远不知道有多少条被静默丢掉了。这一条我在两个项目上都吃过教训。



## 七、验收：怎么证明两份数据是一样的

同步跑通不等于数据对得上，一般做三层校验，从便宜到贵：

```sql
-- 第一层：行数。最便宜，能筛掉绝大部分问题
SELECT COUNT(*) FROM ORDER_MAIN;   -- 两边各跑一次比对
-- 第二层：分片哈希。按主键区间分段取 CHECKSUM，只跑不一致的段
SELECT COUNT(*), SUM(ORDER_ID), SUM(AMOUNT)
FROM ORDER_MAIN WHERE ORDER_ID BETWEEN ? AND ?;
-- 第三层：全量逐行比对。只在核心小表上做，量大慎用
```

顺序别反。行数对不上，直接查；行数对得上但业务方说数据不对，再往下走哈希；哈希也能对上，那问题大概率不在数据本身，去查应用读的是不是那个库。

## 几件我踩过的事

- 全量不分片，单线程跑。不是「慢一点」，是永远跑不完，因为跑的过程中源库还在写，产生新的变化。
- 位点在跑完之后才记。全量期间的变化全部丢失，而且不自知，直到校验阶段才炸。
- CDC 没开主键冲突策略，链路重传一次就多一批脏数据，清理比重做还费劲。
- `HANDLECOLLISIONS` 一直开着。短期救急，长期掩埋问题，一定要在窗口结束前收掉。
- 验收只对大表做了行数。行数一样但内容不一样的情况，我遇到过两次，都是哈希校验发现的。

## 最后

增量还是全量，这个问题本身是个伪选择题。真正要定的是三件事：数据存量有多大、业务能停多久、源库到位点的链路在不在。这三个答案一出来，方案自己就浮出来了。

至于工具怎么选，我这两年的观感是：**决定成败的已经不在 CDC 能不能抓到变化了。** 抓变化这件事各家都做得出来，真正拉开距离的是增量跑起来之后——链路能扛多久不断、延迟能不能看清、出错后多快能恢复、全量阶段能不能并行分片而不是单线程硬跑。这几项在测试环境里都测不出来，得跑一次真实数据量，跑满一个业务高峰。选之前把这一步安排上，比对着参数表比功能有用得多。

好了，今天的复盘就到这。希望你的生产环境用不上这篇，但真遇上迁移，记得回来对一下位点有没有记错。

---

我是DBA小马哥，十年一线数据库运维。写的东西都是生产环境里趟出来的，关注我，少踩坑。


手上有个活儿前后干了快两个月：一个 2.4TB 的订单库从 Oracle 迁到国产数据库，业务不能停，只给了一个周末的割接窗口。

增量同步和全量同步到底怎么选？一个 2.4TB 迁移项目的前后两段

数据库

运维

架构设计

全量与增量同步的适用场景及实操配置全解析，基于2.4TB订单库从Oracle迁移至国产数据库的真实案例。涵盖全量分片并行、增量位点衔接、幂等处理、延迟监控、割接窗口判据等关键环节，并附金仓KFS、MySQL主从、Oracle GoldenGate的具体配置示例。

数据库运维

数据清洗

代码解释

容灾

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

增量同步和全量同步到底怎么选？一个 2.4TB 迁移项目的前后两段-腾讯云开发者社区-腾讯云

增量同步和全量同步到底怎么选？一个 2.4TB 迁移项目的前后两段

增量同步和全量同步到底怎么选？一个 2.4TB 迁移项目的前后两段

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐