数据库同步模式选型：全量增量与CDC拆分策略

云上云下数据库同步、RDS到自建库同步、业务库到报表库同步——这类任务上线前，团队常常会被一个问题带偏：是不是得搞实时？

实时性当然重要，但它远不是唯一判断标准。目标表有没有历史数据？源表有没有可靠的增量字段？删除事件要不要传递过去？源库的日志和账号权限能不能满足要求？任务失败后，怎么证明目标端没少数据？这些问题如果没提前拆清楚，后面排障会非常被动。

全量、增量字段和CDC这三者，不是简单的“低配、中配、高配”关系。全量负责给目标端建立数据基线，增量字段按稳定字段持续推进，CDC则负责捕获完整的变更事件。下面以DataMover的任务配置实践为例，把整个选择过程整理成一份上线前检查清单——希望能帮你少踩几个坑。

先从业务场景反推同步模式

同步模式怎么选？别先看工具支持什么功能，先看业务约束是什么。

说白了：如果目标库还没有基线，第一步通常不是直接上CDC，而是先把历史数据同步过去。如果只是每天同步一次统计表，CDC也可能是过度设计。真正要做的是把完整性、延迟、权限和排障成本放到一张表里综合判断。

全量同步：重点在目标表策略

全量同步适合新库初始化、一次性迁移、历史补数和低频刷新。它的语义最简单：从源表读取完整数据，再写入目标端。

但全量同步上线前不能只看“能不能跑完”，更要看目标端策略。

在DataMover中，普通任务可以用于全量同步。实践中更稳妥的做法是：先用小表跑通源端读取、目标端写入、字段映射和执行记录，再扩大到核心表。页面显示“完成”只能说明任务流程结束了，不能替代目标端校验——这个区别很关键。

增量字段：字段稳定性决定能不能用

增量字段同步看起来轻量，但它对字段质量要求很高。常见字段包括自增ID、update_time、入库时间、业务流水号。

上线前建议按下面这张表检查：

增量字段同步不是CDC的替代品。它适合“可以按字段继续往后追”的表，不适合“必须捕获所有INSERT、UPDATE、DELETE事件”的表。

DataMover的字段映射环节，要重点看主键、时间字段、金额字段、字符字段长度和字符集。异构数据库之间同步时，字段名能对应上不代表语义完全一致——datetime、timestamp、decimal、varchar这些细节都要提前确认。

CDC：不要跳过日志、权限和位点检查

CDC适合实时数仓、业务库到分析库、下游系统接收变更、迁移过程中的持续同步。它能捕获插入、更新和删除，但前置条件比全量和增量字段多得多。

如果使用DataMover配置CDC，需要区分普通任务和实时任务。普通任务更适合全量和增量字段同步，实时任务才用于CDC。上线单中要写清楚：是否执行初始快照？目标表是否已有数据？位点策略是什么？DDL变更由谁处理？

实施过程可以拆成九步

一条同步链路从测试到上线，可以按下面的顺序拆：

1. 确认源库和目标库网络连通性。
2. 确认源端账号读取权限、目标端账号写入权限。
3. 建立源端和目标端数据源。
4. 选择任务类型：全量、增量字段或CDC。
5. 选择源表和目标表，明确是否自动建表。
6. 检查字段映射，重点看主键、时间字段、金额字段、字符字段长度。
7. 小表试跑，观察输入、输出、失败数和错误数据。
8. 执行SQL校验，不只看任务完成状态。
9. 上线后持续观察延迟、失败记录和目标端业务指标。

DataMover的执行监控里要同时看输入量、输出量、失败数、错误数据和日志。同步进度不能单独证明目标端完整一致——目标端约束拦截、字段截断、时间偏移、脏数据写入失败，都可能导致“任务完成但数据少了”。

目标端校验SQL

上线前不要只做行数校验。至少要覆盖行数、时间范围、关键字段聚合和主键抽样。

-- 行数校验
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;

SELECT status, COUNT(*) AS cnt, SUM(amount) AS total_amount
FROM target_table
GROUP BY status
ORDER BY status;

这类校验不能证明所有数据百分百一致，但可以快速发现少行、时间范围缺口、状态分布异常和金额聚合不一致——性价比很高。

几个常见问题

目标表状态没确认

目标表为空和目标表已有数据，是两种完全不同的上线策略。前者通常先建立基线，后者要明确覆盖、追加、写新表还是从当前位点继续。如果没有提前确认，后面很容易出现重复数据或历史数据被误处理。

只因为有update_time就选增量字段

要确认业务更新旧数据时是否一定修改update_time。如果应用绕过统一更新时间逻辑，或者批量修正历史数据但时间字段没变，增量字段同步就会漏——而且很难发现。

CDC没演练重启和位点

CDC的复杂点不只在读取日志，还包括任务重启、位点保存、位点重置和初始快照策略。没有演练过这些动作，故障时很难判断该补全量、重放日志还是从新位点继续。

任务完成就认为数据一致

任务完成只代表执行流程结束，不代表业务数据完全一致。目标端写入失败、字段截断、唯一键冲突、字符集问题——都可能让目标端数据少于源端。这里需要结合执行日志、错误数据和SQL校验一起判断。

上线单建议

如果团队使用DataMover管理同步任务，建议上线单至少记录这些内容：

全量、增量字段和CDC的选择，本质上是在数据完整性、延迟、实施成本和排障复杂度之间做平衡。同步工具可以降低配置和监控成本，但目标表策略、字段可靠性、日志权限和校验流程——这些硬功夫，仍然要逐项确认，一个都不能省。