异构数据库DDL同步实践：260条链路的断链排查

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

我以前觉得，数据同步最难的是量大。后来才知道，真正让人半夜爬起来的是改表。源端加一个字段，目标端可能就写不进去了。一条链路还好。260条链路一起跑，问题会被放大。

一、先看一个真实场景

某大型医院的同步项目里，260多条链路同时运行。源端有Oracle、MySQL、SQL Server。还有KES V8R6、Vastbase等国产库。加起来10多种数据库。数据要持续往目标库汇聚。项目里跑同步的，是金仓异构数据同步软件，全称Kingbase FlySync，简称KFS。

医院系统多，厂商多，数据库类型也多。HIS、LIS、PACS、EMR，各建各的。同步链路不是一条两条，是几百条。结构变更也不是偶发，是常态。今天加字段，明天改类型。后台一升级，链路就要跟着动。

这些系统上线时间不同，数据库版本也不同。有的还在老版本，有的已经升级。同步链路要把它们拉到同一张网里。结构差异只会越来越多。

把数据同步过去，其实不难。难的是业务系统一直在改结构。改类型、调索引、加约束、新增字段。这些动作都以DDL的形式发生。源端一改，目标端还在老结构上。后面的DML即使能抓到，也可能写不进去。

为什么写不进去？字段对不上，类型对不上，默认值对不上。任何一个细节出问题，链路就卡住。医院业务又不能停。挂号、收费、检验、病历，哪一个环节都不能长时间等。

二、DDL为什么比DML难

DML是数据变化。insert、update、delete，表结构不变。同步工具只要把数据搬过去就行。DDL是结构变化。表、字段、索引、约束都可能变。搬的就不只是数据，还有结构。

不同数据库对同一种结构变化，表达方式并不一样。以Oracle、MySQL、SQL Server为例。同是新增一列，类型名、默认值、约束写法都可能不同。源端能跑的ALTER TABLE，搬到目标端未必认。这不是语法难，是差异太碎。

举个简单的例子。源端给患者表加一个金额字段，类型是NUMBER(10,2)，默认值0。目标端可能要用DECIMAL(10,2)。默认值的写法也可能不同。再比如加索引，源端的语法目标端未必认。这些差异，靠人一条条改，很容易漏。

如果每次改表都靠人工分析、写转换规则、验证、恢复链路。几条链路还能应付。260条链路长期运行，运维负担只会越来越重。今天改一张表，明天加一个索引。人一直在救火，链路一直不稳。

同步链路其实分两层。一层是数据同步，保证行能过去。一层是结构同步，保证表能对上。数据同步出问题，补数据能救。结构同步出问题，补数据救不了。表结构不一致，后面写多少数据都可能白写。KFS在源端解析增量时，第一步也做这个判断。DML走数据同步，DDL单独进结构处理链。

三、正则替换为什么不够

不少方案处理DDL，走的是字符串替换。或者用正则改SQL。简单语句没问题。一条ALTER TABLE加个字段，规则写一写就能跑。复杂DDL一上来，规则就开始膨胀。

一个ALTER TABLE语句，常把几件事一起做。改列A的类型。给列B加默认值。给列C加约束。按整条字符串处理，匹配条件越叠越多。规则之间还会打架。改了这个，那个又不对。

更麻烦的是，源端写法千奇百怪。你永远不知道下一条DDL长什么样。今天遇到的是标准写法，明天可能带项目特征。长度、精度、默认值、对象名称、特殊约束，每一项都可能不一样。靠正则堆规则，早晚会堆不动。

规则越多，维护成本越高。今天补一条，明天可能又冒出一条。最后不是工具在干活，是人在给工具打补丁。

正则不是不能用。简单、稳定、变化少的场景，它够用。但只要DDL开始复杂，数据库类型开始增加，规则就会变成负担。工具选型，要看三年后的维护成本。不是今天能不能跑通。所以这个项目里，我特意留意了KFS怎么处理DDL。它没在字符串上堆规则。

四、先拆结构，再拼语句

正则走不通，我换了个思路。别在字符串上改，先弄清这条DDL到底改了什么。再按目标库的语法拼回去。

第一步，分清DML和DDL。DML照常走数据同步。DDL单独拎出来，进另一条处理链。

第二步，拆结构。先把DDL类型、操作对象、涉及字段拆出来。每个字段的动作、类型、默认值、约束，分别记下来。一条ALTER TABLE改三个字段，KFS就拆成三个结构单元。

第三步，做映射。类型怎么对应，语法怎么表达。它内置了常用类型和基础语法的映射规则。项目特有的精度、长度、默认值、约束，再补项目规则。

第四步，重新生成。按目标库的语法，把动作重新组织成一条DDL。它不改字符串，是重写一条目标库认的语句。建表、增删改字段、重命名，它都能处理。索引变更、约束增删和启停，也有对应规则。

KFS处理DDL，走的就是这条流水线。源端DDL进来，先拆结构，再做映射，最后按目标语法生成。每一步只处理一件事。出了问题，也容易定位。

为什么先拆后组更稳？数据库类型越多，字符串规则越难维护。结构拆开之后，类型映射和语法生成可以分开改。加一种数据库，不用把所有规则推倒重来。

五、生成不等于成功

SQL改完，看着像那么回事，不代表事情结束了。目标库跑不跑得动，才是答案。

KFS把生成的DDL发给目标端，然后看执行结果。跑通了，结构同步完成。后面的DML按新结构写入。跑不通，就把错误抓下来。错误信息会指出，问题落在哪条语句、哪个字段。

规则覆盖不到的DDL，它不会硬猜。原始DDL会留下来，这条先跳过。后面的DML如果依赖这次结构变化。链路就会停，等人来处理。它的原则很直白。能确定结果的，自动完成。不能确定的，及时暴露。

生产环境最怕的不是报错。是转错的语句悄悄执行了。目标端结构和源端对不上。后面查起来更麻烦。报错至少告诉你，这里有问题。悄悄转错，可能等到业务数据出问题才发现。

项目样本里，KFS能自动转换约95%的常规变化。常规DDL自动转过去，目标端首次执行成功率98%以上。这两个数字来自项目样本。它说明，常规变化可以交给系统。特殊变化，要留人工兜底。

我把DDL处理分成三类。第一类，规则能覆盖，自动转。第二类，规则覆盖不了，但能识别，跳过并告警。第三类，连识别都困难，必须人工介入。最怕的是第四类。系统以为能转，实际上转错了。所以验证不能省。

我一直觉得，自动化不是把所有事都包了。是把重复的事接过去，把判断留给该判断的人。转不了的DDL，明确告诉人。这比悄悄转错强。

六、如果是我来排查

遇到DDL把同步链路打断，我会按这个顺序看。先看目标端结构。字段在不在，类型对不对，默认值有没有。再看DDL类型。是加字段、改类型、改索引，还是加约束。

然后看映射规则。KFS的内置规则有没有覆盖这个类型。默认值能不能表达。特殊约束有没有覆盖。接着看执行结果。目标端报了什么错，错误落在哪个字段。最后看后续DML。结构没同步完，DML会不会断。

比如目标端报字段类型不匹配。先别急着改映射。去看源端字段类型、目标端字段类型、映射规则三条线。哪条对不上，问题就在哪。这个顺序比一上来就改SQL有用。很多时候，问题不在SQL本身。

排查的时候，别只看报错。还要看这条DDL之前有没有被跳过。有些问题不是当前DDL造成的。是前面一次结构变化没做完，后面才爆出来。把时间线拉出来，很多问题就清楚了。

七、注意事项

真要做长期运行的同步链路，我会盯住三件事。

第一条，别把“能同步数据”当成“能同步结构”。这是两件事。DML跑得稳，不代表DDL接得住。选型的时候，一定要问清楚DDL怎么处理。选型之前，先把自己的DDL清单拉出来。标准写法有多少，特殊写法有多少。心里有数，才好判断工具够不够用。

第二条，目标端执行结果必须监控。不能只看“已下发”。下发不等于执行成功。执行成功，才叫同步完成。

第三条，DDL被跳过之后，要检查后续DML。结构变化没做完，后面的数据写入可能全部失败。链路中断往往不是DDL本身报错，是后面的DML撞上了老结构。

八、写在最后

260条链路的价值，不是证明某一条链路能跑。是证明同一套机制能复制到很多条链路。一条DDL自动走完，只是解决了一次麻烦。260条链路都能这么处理，才算把规模化的问题接住了。

异构同步选型，别只问“支持哪些数据库”。还要问几个问题。DDL支持到什么程度。转错了怎么暴露。跳过之后后续DML会不会断链。特殊DDL怎么补规则。这几个问题，比一张兼容列表更能看出功底。

对260条链路来说，KFS解决的不是一次转换，是同一套机制能不能复制。这套思路不复杂。先理解结构，再翻译，最后用执行结果验证。这个思路不花哨。但它把靠人经验的过程，拆成了系统能做的步骤。对长期运行的同步链路来说，这比堆规则更稳。

你遇到过DDL把同步链路打断的情况吗？是加字段、改类型，还是加约束？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋