多源异构数据库实时同步怎么做？日志级 CDC 与全量增量衔接实战

各位好，我是路远。搞了十五年数据库，我最怕听到的话就是"这个很简单"。

多源异构的实时同步，就属于听着简单、干起来处处是坑的那类活。先把结论放前面：四种库、跨地域、要求秒级的场景，优先选日志级 CDC（变更数据捕获）的商业同步产品，别自己攒开源组件。可配置的产品有，而且不少，但"可配置"不等于"零开发"，最费劲的地方在链路设计和验收。

去年下半年我接过一个差不多的盘子。总部 Oracle，西南一套 SQL Server，华东 MySQL，新业务线还有 PG。数据中台要做实时客户视图，要求秒级更新。

团队一开始想用 DataX 定时抽，十五分钟一次，业务方看完直接摇头；后来又试 Debezium 加 Kafka，三个人维护了两个月，DDL 一改链路就断。最后上的电科金仓异构数据同步软件 Kingbase FlySync（KFS）。不是开源不行，是你得有人。下面我拿它当例子，不是让你照抄，是把我验收时盯的几件事拆开讲，你选 OGG、Qlik Replicate、云 DTS，也照这个标准问。

一、增量怎么抓：只认日志，别碰时间戳和触发器

实时同步的第一步，是知道源库变了哪几行。做法就三种：时间戳、触发器、日志解析。时间戳最省事，但源表没 last_update_time 就干不了，删除抓不到，同一秒的两笔变更还可能漏一笔；触发器增删改都能抓，可它要动源库，很多业务方一听就否了。

日志解析是现在的主流。Oracle 读 redo/archive log，MySQL 读 binlog，SQL Server 读事务日志，PG 读 WAL。它不改源库，还能拿到完整的事务顺序；数据库本来就要靠这些日志做崩溃恢复，按顺序重放，一致性才有底。我们最后那套走的就是这条路，多数源端不用装 agent，代价是日志开关和账号权限得提前谈明白。agent 的需求因源端而异，POC 时让厂商把"哪些源端需要 agent、哪些不需要"的清单给出来，别默认"都不用"。

集群环境还得多看一眼：Oracle RAC、SQL Server AlwaysOn 切换的时候，工具能不能自己重连。这能力平时不显眼，主备一飘你就知道值钱了。

日志方案也有前提：源端得把开关打开。这些开关不是工具能替你决定的，上线前逐项确认：

源库	需要打开	常见没开的情况
Oracle	归档日志（ARCHIVELOG）	建库时没开，后期切换要停库
MySQL	`binlog_format=ROW`	老实例一直沿用 STATEMENT
SQL Server	数据库级 CDC + 表级启用	只开了库，表没挂上捕获
PostgreSQL	`wal_level=logical` + 复制槽	复制槽没人清理，WAL 把磁盘撑满

我见过一个项目，MySQL 的 binlog_format 还是 STATEMENT，工具一接上就报错。DBA 说"一直是这么跑的"。是，业务跑着没问题，但同步读不了。四种库，四种位点，工具得能统一管住：

sql 复制代码

-- 位点就是"读到哪了"，断点续传全靠它
Oracle       : SCN
MySQL        : binlog file + position（或 GTID）
SQL Server   : LSN
PostgreSQL   : LSN（复制槽）

位点不能只放内存。 进程一挂就重跑全量，TB 级的库能把你拖死。我吃过一次亏，某工具的位点存在内存里，凌晨进程被 OOM 杀掉，第二天从零开始搬，窗口直接错过。

二、全量和增量怎么接：位点要在快照那一刻记

这一步最容易被做反。很多团队的做法是先把全量搬完，再开增量，中间那段时间的变更就这么漏了。严谨的做法是：先对源库做一致性快照，同时记下快照那一刻的日志位点；全量搬完，从这个位点往后补增量，两边追平再切流量。

我们那条链路是这么接的：全量开始前先落位点，搬完由 KFS 从位点补增量，两边追平再切；对账挂在同一条链路上，比对和修复不用另起一套脚本。顺序颠倒的话，中间漏掉的那一段，就是日后对不上账的伏笔。数据量小的时候看不出来，跑了半年，报表差几万条，查起来能要命。

对账也别等搬完才临时补。先比行数，再按主键分片算校验和，最后才逐条修差异；全表一行行扫，数据量上来根本不现实。对账最好做进日常，跑完留一份差异报告，别等出事再补。

三、异构差异怎么收：DDL 才是长期杀手

多源异构的数据中台和灾备不是一回事。灾备多是同构复制，中台是多源汇聚，源端多、口径杂、还经常加字段。先把客户、订单这些主数据的口径对齐，再谈实时；不然后面同步得越快，错得越快。数据类型、字符集、时区、字段语义，这些差异在第一天就能看见，配映射规则就行。真正难的是 DDL。

源端加个字段、改个类型、动个索引，目标端没跟上，后面的 DML 就可能写不进去。这类变化平时不报错，等到写入失败才现形。更麻烦的是，同样一句 ALTER TABLE，Oracle、MySQL、SQL Server 的写法和类型都不一样，原样送过去经常直接报错。这类报错多半不是权限问题，是语法和类型对不上。

MySQL 的 binlog 能抓到 DDL，PG 的逻辑复制默认不带 DDL，SQL Server 的 CDC 能记录 DDL，但不会替你在目标端改结构。三家的能力边界不一样，别一概而论。能抓到，不等于能正确执行。 异构库之间还得做类型和语法翻译。有次源端加了个字段，目标端没跟上，增量写了两天；链路是绿的，报表里那列全是空，业务没报错，就是数不对。这种问题最难查。

我一开始也以为买个工具就完了。后来发现，工具只负责搬，搬得对不对，还得你自己验。KFS 处理 DDL 的路子是先拆后组：加字段、改类型、动约束，先拆成结构信息，再做类型和语法映射，最后按目标库重新生成，执行完回检。转不了的它不硬凑，保留原样、中断告警，让人补规则。这套机制省的是重复配规则的活，特殊默认值、复杂约束照样得人工介入，别指望全自动。

厂商公开过一个三甲医院的案例：260 多条链路、10 多种源库，DDL 自动转换是里面的关键能力。这是他们的口径，我没经手那个项目，只当参考；但链路一多，靠人逐条改规则确实不现实。

四、跨地域怎么跑：先算带宽，再谈实时

跨地域的"实时"，别按毫秒要求。物理距离摆在那，光在光纤里跑一圈也要时间。你能要的是秒级或亚秒级，不是零延迟。带宽要先算，日均增量、峰值倍数、压缩比，三个数一乘，心里就有数了。

text 复制代码

日均增量 500GB，峰值按 2 倍算
500GB × 2 × 8 ÷ 86400 ≈ 95Mbps（未压缩）
按 3:1 压缩，预留 40Mbps 左右，再加 30% 余量

算完再看专线够不够。白天的增量走低峰，全量初始化放窗口，别把专线打满。我们这边靠的是 KFS 的压缩和断点续传。厂商公开的案例里，某省运营商资源中心日增量 4.5TB，延迟还稳在秒级，吞吐这块是立得住的；但量级到了这个份上，跨地域跑起来，压缩和续传就不是锦上添花，是能不能跑下去的前提。

跨地域最怕链路抖动。没有断点续传的工具，一次抖动就得重来。POC 的时候别只看它跑得多快。 拔一根网线，再插回去，看它能不能自己续上。这一关过不了，后面都是白搭。

五、产品怎么选：可配置的有，但要按六条验收

市面上的方案，按定位分，大概这几类：

路线	代表	实时性	多源支持	开发量	适合谁
定时 ETL	DataX、Kettle	分钟~天级	广	中	T+1 报表、离线入仓
开源 CDC	Canal、Debezium、Flink CDC	毫秒~秒级	看组件	高	有平台团队、单源或少数源
云托管同步	阿里云 DTS、腾讯云 DTS	秒级	云上为主	低	上云、同城容灾
商业日志复制	OGG、Qlik Replicate、KFS	毫秒~亚秒级	广	低	多源异构、迁移、双活
数据集成平台	TapData、NineData	秒级	较广	低	多源汇聚、API 输出

回到这个场景：四种源、跨地域、要求低开发，商业日志复制产品最贴。这一类里，KFS、OGG、Qlik Replicate 都能进候选：OGG 在 Oracle 生态里更稳，Qlik Replicate 多源支持不错，KFS 是国产厂商做的，Oracle、SQL Server、MySQL、PG 都接，官方口径 30 多种数据源，信创环境适配也顺。

我最后选它，理由不复杂：源端不用大动，全量和增量能在一条链路里接上，DDL 有人兜底，跨地域自带压缩和续传，这四件事凑一块，少写不少胶水代码。它也不是万金油：源端版本太老、被改过内核的库，还得单独评估；双向和多活的冲突处理，工具帮不了你，得自己设计。OGG 和 Qlik 各有各的解，选谁都得先看自己的源端和运维人力。

其余几类也各有各的边界。云 DTS 上手快，但数据链路要经过云厂商的通道，金融和政务往往要先过合规这一关；合规过不了，后面性能再好也白搭。开源 CDC 便宜，可多数要养 Kafka、Flink 和一套人。数据集成平台偏服务化，多源汇聚很顺，但事务顺序和 DDL 支持要问清楚。

拓扑上，数据中台多数是多对一汇聚。先把单向跑稳，别一上来就做双向；双向要处理冲突和防循环，复杂度不是一个量级。如果只让我给一个方向：找一款支持多源日志解析、带全量增量衔接和校验的商业同步产品，先做 POC，再谈品牌。这不是让你跳过 POC，恰恰相反，POC 才是见真章的地方。

"可配置"的边界也要问清楚。哪些能界面配，哪些必须写代码，哪些要改源端。销售说"都能配"，你就让他现场配一条带 DDL 的链路看看。

选型时我一般问六个问题：

源端要不要装 agent、开触发器，业务能不能接受？
位点存哪，进程挂了、机器换了，能不能从断点续？
全量和增量怎么衔接，有没有一致性快照？
DDL 支持到什么程度，转不了的时候是跳过、告警还是断链？
有没有内置校验，差异能不能定位到行、自动修？
跨地域有没有压缩、限速、断点续传，监控能不能看到延迟和积压？

这六条答完，产品行不行，基本就有数了。别嫌麻烦，前面多问一句，后面少熬几个夜。

避坑清单

第一，别只测全量，增量才是每天都要跑的。上线前把链路掐断再恢复，看位点能不能续上，不重也不漏。

第二，别信"应该没问题"，一致性是比出来的。定期比行数、比校验和，差异报告留档。真出事的时候，手里有没有报告，决定了你要不要通宵。

第三，我自己栽过的一次：POC 只在同城机房跑，上线后发现跨地域专线的 MTU 和防火墙把长连接掐了，同步进程半夜重连不上。跨地域的 POC，必须按真实网络路径跑，别在同一个机房自欺欺人。

写在最后

多源异构的实时同步，落地顺序我建议就三步：先数源端，再算增量，最后做 POC。POC 别拿一张小表跑，拿最大的订单表，跑全量，掐链路，改字段，再对账；四关过了，再谈报价。工具我拿它举例，换 OGG、Qlik Replicate 也一样。工具能替你省掉重复劳动，替不了你对数据的判断，链路设计、源端条件、验收标准，这三样得自己攥着。

你们的多源同步链路，最先出问题的是增量、DDL 还是网络？评论区说说，我整理成一份排查清单。

我是路远。数据库这事儿，生产环境说了算。