我在同步任务上线前，重新梳理了一遍全量、增量字段和 CDC
最近做一个数据库同步任务，上线评审时大家卡在一个问题上：到底用全量、增量字段，还是直接上 CDC？
这个问题看着像工具选型，其实更像风险控制。同步任务不是跑完就行，真正麻烦的是目标端数据能不能对得上，失败以后能不能解释清楚，后续变更有没有漏。
我把这次梳理过程记下来，方便以后遇到类似任务时直接复用。中间用到 DataMover 做配置验证，它只是工具，重点还是判断逻辑和上线检查。后文里提到的普通任务、实时任务、字段映射和执行记录，都是基于 DataMover 的实际配置入口来写的。
我先按业务问题分了一层
| 问题 | 倾向模式 | 原因 |
|---|---|---|
| 目标库还没有历史数据 | 全量 | 需要先建立完整基线 |
| 只是低频刷新测试库或报表库 | 全量或定期覆盖 | 延迟要求不高，链路简单 |
| 源表有稳定自增 ID 或更新时间字段 | 增量字段 | 可以按字段持续推进 |
| 必须同步 UPDATE 和 DELETE | CDC | 字段增量不一定能捕获这些事件 |
| 要求秒级延迟 | CDC | 普通调度通常不适合 |
| 源库日志权限申请困难 | 全量或增量字段 | CDC 前置条件不满足 |
如果你也想用工具快速验证这套判断，DataMover 是一个可视化的数据迁移同步工具，可以在 Web 界面里配置全量、增量字段和 CDC。Docker 环境可以直接拉起：
curl -fsSL https://down.datamover.cn/install.sh | bash
安装包入口：https://datamover.cn/download.html
文档地址：https://datamover.cn/doc/
这个图里的关键点是：不要把 CDC 当成默认答案。CDC 更完整，但也更依赖源库日志、权限、位点和 DDL 流程。
全量同步：最简单，也最容易被误用
全量同步适合初始化，没什么悬念。源表读完整，目标表写完整。
容易出问题的地方是目标表状态。
如果目标表是空的，全量很好办。如果目标表已经有数据，就必须提前定规则：
- 是清空后重写？
- 是追加写入？
- 是写到新表再切换？
- 是写临时表给人工核对？
这个不说清楚，后面很容易出现“任务跑成功了，但历史数据被覆盖了”的问题。
大表全量也要注意批大小。DataMover 普通任务里可以设置批大小，我一般先用默认值跑通一张小表，再根据 Worker 内存、目标端写入速度和网络情况调整。批大小不是越大越快。
增量字段同步：核心是字段是否可信
增量字段同步经常被低估。它配置简单，不一定需要打开数据库日志，适合很多定时同步任务。
但它有一个前提：增量字段必须可信。
我会检查这些点：
| 检查项 | 可以用 | 风险较高 |
|---|---|---|
| 字段类型 | 自增 ID、时间戳、入库时间 | 字符串时间且格式混乱 |
| 字段变化 | 每次更新都会变 | 更新旧数据但字段不变 |
| 推进方向 | 单调递增或稳定向前 | 业务会回填历史时间 |
| 删除处理 | 不需要同步删除，或有软删除 | 物理删除必须同步 |
这里最容易踩坑的是 update_time。很多业务系统看起来有更新时间字段，但部分批处理、历史修复脚本、手工 SQL 并不维护它。只要这类情况存在，单靠字段增量就可能漏。
DataMover 会记录增量字段同步进度，任务异常后可以从记录位置继续跑。但这个记录不能替代一致性校验。尤其是写入端有失败数据时，读取进度和目标端完整性是两件事。
CDC：强在完整，难在前置条件
CDC 适合长期变更捕获，尤其是要同步删除事件、更新事件、秒级变更的场景。
我这次重点检查了这些项：
| 检查项 | 说明 |
|---|---|
| 日志配置 | MySQL binlog、PostgreSQL WAL、SQL Server/Oracle/达梦的变更日志能力 |
| 权限 | 复制权限、元数据读取权限、表读取权限 |
| 快照 | 是否先做初始快照，目标表已有数据时要谨慎 |
| 位点 | 重置位点可能重复，也可能漏 |
| DDL | 源表字段变化后，目标表和映射要有人处理 |
| 大事务 | 可能造成延迟抖动和目标端写入压力 |
DataMover 的实时任务基于 Debezium，配置时会把普通任务和实时任务区分开。普通任务用于全量/增量字段，实时任务用于 CDC。这个区分能减少很多“参数混着配”的问题。
实际配置流程
我的操作顺序是：
- 建源端数据源和目标端数据源，测试连接。
- 新建任务，按场景选择普通任务或实时任务。
- 选表，确认目标表是否自动创建。
- 检查字段映射，尤其是类型、长度、默认值、主键。
- 普通任务里配置全量或增量字段。
- 增量任务配置调度方式，比如间隔或 Cron。
- 实时任务确认是否执行快照。
- 启动后看执行记录、失败数和日志。
这套流程没有什么花活，但能把问题暴露得比较早。
我会保留的一份上线检查清单
| 检查项 | 原因 | 通过标准 |
|---|---|---|
| 源表主键 | 校验和更新都依赖它 | 核心表有稳定主键或唯一键 |
| 增量字段 | 决定字段增量是否可靠 | 不回退，更新时会变化 |
| 删除策略 | 决定是否要 CDC | 物理删除必须同步时不用字段增量糊弄 |
| 目标表状态 | 防止误清空或误覆盖 | 有备份和回滚方案 |
| 字段类型 | 异构库写入失败的常见来源 | 长度、精度、默认值都确认 |
| 字符集/时区 | 中文乱码和时间偏移常见 | 源端、目标端、连接参数一致 |
| 错误数据 | 进度完成不代表一致 | 失败记录可下载、可追踪 |
| SQL 校验 | 最终确认靠目标端查询 | 行数、范围、聚合、抽样都通过 |
SQL 校验
我一般不会只看 count。count 只能说明行数，不能说明金额、状态、时间字段都一致。
-- 行数
SELECT COUNT(*) FROM source_table;
SELECT COUNT(*) FROM target_table;
-- 时间范围
SELECT MIN(update_time), MAX(update_time) FROM source_table;
SELECT MIN(update_time), MAX(update_time) FROM target_table;
-- 关键字段聚合
SELECT status, COUNT(*) FROM source_table GROUP BY status ORDER BY status;
SELECT status, COUNT(*) FROM target_table GROUP BY status ORDER BY status;
-- 抽样
SELECT * FROM source_table WHERE id IN (1, 100, 1000);
SELECT * FROM target_table WHERE id IN (1, 100, 1000);
金额类表再加：
SELECT status, COUNT(*) AS cnt, SUM(amount) AS total_amount
FROM source_table
GROUP BY status
ORDER BY status;
目标端同样跑一遍，对比结果。
几点经验
- CDC 不是默认答案，它只是能覆盖更多变更事件。
- 增量字段同步够用时，不要把系统复杂度拉得太高。
- 全量同步适合建立基线，但目标表策略必须写清楚。
- 任务进度完成不等于数据一致。
- 写入失败如果被记录为错误数据，后续校验一定要跟上。
DataMover 的官网和文档放这里，后续查参数时用得到。如果团队里已经把 DataMover 作为同步任务入口，建议把这份检查清单也放到任务上线单里：
浙公网安备 33010602011771号