做数据库迁移和同步不少人的第一反应是上应用层双写或者套一个第三方CDC工具。但如果你正在做的项目涉及达梦数据库而且要求Oracle或MySQL和达梦之间做准实时数据同步那达梦官方自带的DMHS这套实时同步组件基本是你绕不开的核心选项。这篇文章不聊PPT上的宣传指标只记录我最近一次基于DMHS在MySQL和达梦之间搭建双向同步的完整过程从整体架构拆解、环境准备、任务配置到双向防循环设计以及中途踩过的各种坑。如果你正准备上手DMHS或者已经在排障路上绕圈子这份部署实例应该能让你少走不少弯路。1. 整体设计与架构拆解1.1 为什么最终选了DMHS我在做这个项目之前先把市面上常见的同步方案都过了一遍。应用层双写最直观业务代码里同时写两个库但牵扯事务一致性、失败补偿、接口超时等一系列问题而且改造量大几乎等于重写数据访问层。基于binlog的第三方同步工具虽然生态成熟但面对达梦时生态支持就很尴尬不少工具要么不支持达梦作为目标端要么需要额外写插件。DMHS是达梦自带的实时同步组件走的是日志解析路线源端读取本地日志目标端执行装载对业务系统来说基本无侵入。这意味着应用代码不用改数据库账号只需要具备读取日志和写入目标库的权限。对异构数据库场景来说这种“日志级同步”的侵入性优势非常明显。还有一个现实因素客户要求后期的运维边界清晰。如果是自研同步逻辑一旦出问题排查链路会很长如果是DMHS官方对达梦侧的行为有明确约束问题定位能限定在配置和网络层面。从交付角度看选择官方组件后续维护和文档说明都有据可查。1.2 单向同步到双向同步的差异很多项目一开始只提单向需求比如“把老系统的数据同步到新系统”。但业务一旦跑起来两边系统都会有人操作单向很快就满足不了。我这次的需求很明确MySQL侧的应用继续读写达梦侧的应用也要读写两边数据要尽量保持一致这就是典型的双向同步。单向同步和双向同步并不是“把任务反过来再建一遍”这么简单差异主要体现在三个方面维度单向同步双向同步任务数量一个同步任务即可至少两个任务方向相反数据流向源端到目标端单向流动两端互为源和目标双向流动冲突风险低基本不会出现双写冲突高同一记录可能被两端同时修改防循环要求不需要额外设计必须考虑环路问题初始实施成本较低配置简单较高需要逐表规划同步方向从架构上看双向同步的每一端都需要部署一套DMHS服务。A库上的DMHS负责把A库的变更推到B库B库上的DMHS负责把B库的变更推到A库。两套任务独立运行互不依赖。但这里有一个关键细节也是很多人容易忽视的双向同步不等于双活双写。如果同一张表在两端都允许应用直接修改那同步回灌产生的环路和冲突会非常难处理。我后面会在部署章节详细讲怎么通过表级方向割分来规避这个问题。1.3 DMHS各组件的角色分工DMHS整体上分三个主要部分部署在源端的服务组件、部署在目标端的执行组件以及用来管理配置和监控的控制台组件。源端组件负责读取日志、解析变更、发送数据目标端组件负责接收数据并写入目标库控制台组件负责创建同步任务、启停服务、查看运行状态。用一个生活化的类比来说源端组件像抄写员盯着源库日志把新发生的变更一条条抄下来网络传输像快递链路把抄写的内容运到目标端目标端组件像入库员把快递内容逐条写进目标库。控制台则像调度室你只需要在调度室查看全局状态。这个分工决定了部署位置源端和目标的服务器上必须分别装好对应组件控制台可以装在管理机上远程连接。规划网络时要注意两端之间的端口连通性防火墙策略需要提前放行否则配置好了任务却连不上排查起来相当费时间。2. 环境准备从达梦安装到连接链路打通2.1 达梦数据库本身的安装要点要搭建DMHS同步环境前提是达梦数据库实例能正常跑起来。目前用到比较多的还是DM8安装过程本身不算复杂但有几个初始化参数会直接影响后续同步必须在一开始就确认清楚。页大小在达梦里一旦初始化完后期没法轻易修改。页大小选择要考虑业务表行宽和实际存储场景如果一张表的单行数据较大页太小会导致行跨页查询性能受影响。经验上是根据最大表行宽和并发场景综合判断而不是统一用默认值。字符集也一样关键。如果源端MySQL用的是UTF-8达梦初始化时最好也选择UTF-8如果源端是GBK两边也要尽量对齐。字符集不一致同步过来的中文字段非常容易出现乱码。我这次把两端都统一到了UTF-8省掉了后续编码转换的麻烦。大小写敏感性决定了SQL里表名和列名的匹配方式。达梦初始化时可以选择大小写不敏感业务侧可以直接用大写表名操作。这个参数在DMHS同步任务配置时也需要注意过滤条件里如果出现表名字段大小写规则要跟库内实际存储一致。初始化完成后要确认数据库服务已经启动默认的管理员账号能正常登录同时记录好实例名和端口默认端口一般是5236。还有一步容易被忽略检查是否启用了本地归档。DMHS靠读取日志来捕获变更如果源端达梦没有开启归档日志被复用覆盖后同步任务就拿不到完整的历史变更数据。这是部署DMHS前必须确认的前置条件。2.2 连接工具与驱动的那些坑环境准备好之后第一件事是验证数据库连接是否正常。Navicat这类通用客户端连接达梦需要选择对应的数据库类型并加载达梦驱动。如果驱动没配好或者类型选错通常会报连接失败或驱动类找不到。实际排查中我发现大部分连接问题并不是密码错误而是服务名选错、实例未启动、驱动版本不匹配。比如报“用户名或密码错误”且错误码是-2501很多人第一反应是去重置密码但有时候只是客户端没有正确指定目标实例。建议排查顺序是这样排查项具体操作常见结果服务是否启动在达梦服务器上检查数据库服务进程未启动则启动服务端口是否连通telnet到目标端口比如5236不通则检查防火墙实例名是否匹配确认连接配置里的实例名与dminit创建时一致不一致则报错或连错实例驱动版本使用与数据库版本匹配的JDBC驱动版本太老可能连不上账号权限确认账号具备同步所需权限权限不足则无法创建任务达梦驱动一般跟随安装包提供在安装目录的jdbc子目录下能找到对应的jar包。Java项目引入时如果公司Maven私服没有坐标可以直接用系统依赖方式把本地jar包引入工程简单直接。Spring Boot项目接入时还需要注意Druid连接池和达梦驱动的兼容性我遇到过Druid对达梦的DbType识别不准的情况需要手动指定连接参数。2.3 DMHS安装与授权注意事项DMHS的安装包同样来自达梦官方渠道安装时注意版本要和数据库版本匹配不同版本之间的协议细节有差异混用容易出现同步中断或解析失败。安装完成后还需要配置授权文件也就是常说的key。授权文件有有效期到期后同步服务会停止工作。我在实际项目中遇到过授权到期后任务中断的情况重启服务无效查日志才定位到是授权过期。这里给大家一个建议把授权到期时间记录到运维日历里提前一个月安排更新同时了解授权更新流程避免到期当天手忙脚乱。DMHS服务启动前最好先检查安装路径下的配置模板确认监听的端口、日志目录、工作目录等参数。日志目录尤其重要排障时如果日志目录在系统盘且空间不足同步任务会异常退出。我习惯把日志和临时数据单独放到数据盘并配置好日志轮转。3. 部署实操从单向任务到双向同步的实现3.1 历史数据初始化同步的前提DMHS解决的是增量同步已经存在于源库里的历史数据不会自动同步过来。所以你需要在启动DMHS任务之前先把源库的历史数据迁移到目标库业界通常叫“基线导入”。我这次的处理方式是先对MySQL侧的业务表做逻辑备份然后在达梦侧恢复。这里要注意字符集和表结构的兼容性MySQL的自增列、时间类型、字符串类型在达梦里的表达方式有差异。比如MySQL的datetime类型到达梦后如果建表语句不调整可能会因为精度或默认值问题导致数据导入失败。基线导入完成后一定要做行数校验和关键字段抽样比对。用“同一条记录在原库和目标库内容一致”来验证迁移质量不要只看总数对得上就放开手配置同步。数据质量问题如果拖到增量同步阶段才暴露定位成本会成倍上升。在正式配置DMHS任务之前还要记录一个时间点基线导入完成的时间。这个时间点是增量同步的起点参考。如果DMHS支持从某个日志位置开始解析那就把起点定位在基线完成的时刻附近尽量避免漏数据或重复数据。3.2 配置同步任务对象、连接和过滤条件配置同步任务时需要把同步对象明确到表级。不需要同步的表不要一股脑全部加进来每加一张表后续的监控和冲突处理就多一份负担。我这次只选择了业务核心表比如订单主表、订单明细表其他配置表另作处理。配置结构大致是这个思路以MySQL到达梦方向为例同步方向MySQL - 达梦 源端连接源MySQL库的连接信息 目标端连接目标达梦库的连接信息 同步对象 - 表 orders同步时排除某些无业务价值的字段 - 表 order_items按时间条件过滤数据 冲突策略目标端已存在相同主键记录时根据业务选择跳过或覆盖这只是配置思路示例具体参数名以你手里的DMHS版本模板为准。核心要表达的是在创建任务之前把同步对象、过滤条件、冲突策略都想清楚而不是建完任务发现问题再回来改。过滤条件是个好东西。如果业务上只需要同步最近一年的订单可以在任务里加时间过滤条件减少无效数据传输。但过滤条件也需要定期检查曾经遇到一个任务配置了时间过滤业务数据延迟写入导致部分记录绕过过滤条件两边数据对不齐排查了很久才发现是过滤条件与业务行为不匹配。3.3 双向同步的防循环设计双向同步最核心的技术难点是防止数据“回灌”。假设A库和B库都部署了同步任务A库的一条数据变更被任务1同步到B库后B库里会生成新的日志。这条日志如果不加区分又被任务2捕获回A库A库再次变更再同步到B库数据就像乒乓球一样在两个库之间来回跳形成无限循环。规避环路的设计思路我实际用过三种按推荐程度排序第一种是表级方向割分。每张表在规划时只指定一个同步方向比如订单表只做MySQL到达梦同步商品表只做到达梦到MySQL同步。两端应用分别只写各自负责的表两边数据最终都能看到全量数据但同一张表的变更只走一条链路从根本上不会产生环回。第二种是行级方向标记。如果业务上必须有同一张表双向同步可以在表里增加一个来源标记字段源端应用写入时维护该字段同步任务通过过滤条件跳过本端标记的数据。比如标记值为A的数据只允许从A同步到BB侧任务读取时过滤掉标记为A的记录这样B侧应用产生的变更写的是标记B不会把A同步过来的数据再次同步回去。第三种是依赖DMHS自身控制能力。不同版本对环路控制的支持不一样需要仔细看官方文档确认参数行为。如果版本支持可以试试在任务上开启回环控制相关配置。我最终采用的是表级方向割分方案。虽然需要和业务确认每张表的归属方向前期沟通成本高一点但运行期的数据一致性和可维护性最好排障时思路清晰不会出现两边数据反复覆盖的问题。3.4 启动、监控与数据验证任务配置完成后启动前先检查日志目录权限和磁盘空间避免运行一段时间后日志把盘写满。启动同步任务后不要马上认为万事大吉先用一条测试数据跑一遍完整链路。我当时的验证步骤是在MySQL侧往订单表插入一条新记录然后在达梦侧观察是否在预期时间内出现对应记录。确认正向同步正常后再在达梦侧修改一条记录的备注字段观察MySQL侧是否出现同步修改。两边都验证通过再把应用流量逐步切过来。监控方面DMHS控制台可以查看同步任务的状态比较直观的指标是同步延迟。我建议设置一个延迟阈值比如超过一分钟就告警。延迟突然飙升往往意味着源端归档没有及时生成或者网络链路有问题。可以把状态查询做成定时脚本将结果推送到运维群这样出了问题不用等到业务侧反馈才后知后觉。4. 常见问题与排查技巧实录4.1 连接报错“用户名或密码错误”的真相这个报错我见得太多了尤其是用Navicat连接达梦时客户端提示用户名或密码错误错误码-2501。大部分情况下用户第一反应是改密码但真正原因可能是客户端和服务端字符集不一致导致提示信息显示异常也可能是连接配置中的服务名与实际实例不匹配。之前接手一个环境用户拿着报错截图来找我说密码怎么改都对不上。我坐过去一看连接配置里的服务名写了一个不存在的实例系统实际实例名是另一个Navicat拿着错误的服务名去连接自然报凭据错误。把服务名改正后同一组账号密码直接就通过了。遇到这类报错我建议大家按顺序检查先确认实例是不是真的启动了再用命令行工具在服务器本地连接测试最后才轮到排查网络、驱动、账号权限。本地能连而远程连不上问题基本在网络或防火墙本地都连不上问题大概率在数据库配置。4.2 字符集引发的“乱码连环坑”字符集问题在异构数据库同步里出现的频率非常高。创建达梦实例时如果没有选对字符集同步过来的中文数据很可能变成乱码。更隐蔽的是客户端本身的字符集设置也会影响显示我在热词里看到有人把“用户名或密码错误”认成了乱码其实那只是客户端把UTF-8内容按GBK渲染了。乱码在MySQL和达梦两侧的排查思路不一样。MySQL侧要检查连接参数里的characterEncoding和表字段字符集达梦侧要检查实例字符集和客户端连接字符集。两端不一致时同步过来的中文在沿途每个环节都可能被转码一次越转越乱。经验是达梦实例初始化阶段就把字符集定为UTF-8应用连接串显式指定字符集不要依赖数据库默认值。如果已经建好的实例字符集不对最干净的做法是逻辑导出数据、重新建实例、再导入数据。调整实例字符集的代价比较大所以初始化阶段就要定好。4.3 双向同步的数据冲突处理双向同步跑起来之后最头疼的问题是同一张表在两个库同时被更新。比如MySQL侧把订单状态改成已发货业务人员又在达梦侧把同一订单的备注改了两个方向的同步任务都生效最终哪个值被覆盖取决于时间顺序和任务执行顺序。这里我强烈建议在业务层面尽量把同一实体在两个端的写入时间错开。如果无法错开可以引入最后更新时间戳字段同步时用时间戳判断保留更新的值。但这不是万能的极端情况下时钟偏差会导致错误覆盖。更稳妥的思路还是表级方向割分。把双向同步设计成业务上应用侧单边写另一端只读这样数据只在固定方向流动冲突概率降到最低。双向同步的可用性优势主要体现在读扩展和容灾上而不要贪心让两端同时承担写压力。4.4 同步延迟飙升和日志导致的坑同步延迟上升时我一般先查源端日志归档情况。如果达梦侧没有开启归档或者日志空间配置太小日志很快被覆盖DMHS解析不到完整变更任务会表现异常甚至中断。这个坑在测试环境不容易暴露因为数据量小生产环境跑一两天就会爆发。如果确认归档没问题再看两端的时间同步。服务器时钟偏差会直接影响同步速度判断甚至影响基于时间的过滤条件判断。生产环境强烈建议所有服务器都配置NTP时间同步。还有一次我排查一个同步延迟越来越大的问题查到最后发现是源端表没有主键。DMHS在日志中逐行变更解析时没有主键的表无法高效定位变更目标导致同步性能断崖式下降。这给我们的启示是同步对象的表尽量都有主键没有主键的表要么改造业务要么加强监控。现象可能原因优先排查方向连接报错类提示服务名或驱动问题实例状态、连接配置中文乱码字符集不一致实例字符集、连接参数同步延迟高归档未开或表无主键归档配置、表结构双向数据被覆盖冲突策略未设计好同步方向规划、时间戳字段任务突然中断授权过期或日志空间满授权有效期、磁盘空间5. 实操心得与后续扩展建议整套环境跑通后我对DMHS的看法更务实了。它确实能解决异构数据库之间的增量同步问题但前提是前期规划做得足够细。表的方向归属、过滤条件、冲突策略这些设计工作占整个项目比重的四成都不夸张。我个人体会比较深的一点是双向同步一定要先以单向同步为基础跑稳。先搭一条MySQL到达梦的单向链路通过数据和延迟验证确认整条链路没有问题了再叠加反向链路。一次直接把两条链路都搭好出了问题时很难判断是正向链路的问题还是反向链路的干扰。另外数据校验应该做成定期任务。每天凌晨业务低峰期对比两端表行数和关键字段校验值哪怕只是抽查核心表也能尽早发现同步遗漏。同步链路越复杂越需要靠数据比对来兜底不能只依赖同步任务自身的状态监控。如果需要做数据一致性校验也可以关注一下达梦自带的校验工具或通用比对方案。成本不高收益明显。这个项目结束之后我还在想能不能把同步任务再做细致一点比如按业务类型拆成多个任务这样某个任务出问题只影响对应的业务子集不会导致全库同步停摆。后续如果要做达梦和Oracle之间的同步思路也是共通的核心还是想清楚同步对象、方向和冲突处理这三件事。