数据库同步模式选型实践：全量、增量字段和 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 的选择，本质上是在数据完整性、延迟、实施成本和排障复杂度之间做平衡。同步工具可以降低配置和监控成本，但目标表策略、字段可靠性、日志权限和校验流程仍然要逐项确认。