简介《迪思杰RealSync部署手册.doc》是一份面向数据库运维、数据同步项目实施人员的解决方案型文档围绕RealSync复制软件在源端与目标端的安装与配置展开。内容按部署流程组织先在源端与目标端完成操作系统用户、数据库用户等前置创建并结合源端创建数据库视图随后依次执行登陆主机、安装软件、启动Agent与Dbpsd并延伸至注册主机与数据库信息、配置同步内容、发起首次同步等环节覆盖从环境准备到复制启动的完整链路。压缩包共1个doc文件大小约129KB目录层级与步骤编号清晰适合作为现场实施的操作清单。目前已有128人学习下载对初学DSG RealSync或需要快速落地数据复制任务的运维人员有直接参考价值。1. 迪思杰 RealSync 是做什么的先说结论再说适合谁数据库实时同步这件事听起来就是把 A 库的数据搬到 B 库但要保持两边实时一致、不丢事务、还能跨异构数据库就没那么简单了。迪思杰 RealSync 就是干这个的它通过解析源库的在线日志和归档日志把每一次增删改按事务顺序重放到目标库做到准实时同步。很多 DBA 第一次拿到这份《迪思杰 RealSync 部署手册.doc》以为照着装完就算完事真正上手才发现坑全在配置和运维细节里。这篇笔记就按我实际做过的项目从原理、部署、排错到验证把这条链路讲透。适合正在做 Oracle、达梦、MySQL 之间数据同步或者准备上双活、读写分离、数仓供数的人看新手能照步骤走熟手可以直接跳到避坑章。2. 同步架构与选型日志解析为什么是第一道坎2.1 逻辑复制 vs 物理复制RealSync 为什么选日志解析这条路部署 RealSync 之前先要明白它和 DataGuard、MySQL 主从这类物理复制不是一回事。物理复制传的是数据块把源库的数据文件变更原样搬到目标库优点是延迟低、一致性强缺点是目标库必须同平台、同版本连文件系统布局都可能被绑死。逻辑复制传的是变更记录从日志里解析出这是哪张表、哪个主键、改了什么字段再把这段变更翻译成目标库能执行的 SQL 或中间格式。RealSync 走的就是这条路。选逻辑复制的理由很实际一是异构同步常见的组合是 Oracle 到达梦、Oracle 到 MySQL、MySQL 到国产库二是可以做双向同步或数据汇聚物理复制很难在复杂拓扑里做到这一点三是同步过程可以带过滤和转换规则比如只同步某些 schema、只同步某些表。代价就是实现复杂度高日志解析稍微出点偏差数据就对不上。所以第一道坎不在同步本身而在源库日志的准备程度这个第 3 章会细讲。2.2 三个端口各司其职捕获、传输、接收不能省RealSync 部署起来像一条流水线源端、传输、目标端各自有独立进程这也是它跟很多同步工具最大的区别。常见的做法是部署进程管理软件在源库所在服务器上装一套目标库服务器上装另一套。源端这侧跑的是日志捕获进程它连着源库不停读取日志并解析成标准格式然后写到本地队列或直接推给目标端目标端那侧跑的是接收和应用进程把收到的变更在目标库上重放。中间还可以加一个分发层实现多对一汇聚或者一对多分发。这个三段式架构的好处是捕获进程不直接依赖目标库的运行状态目标库暂时不可用源端日志还能继续读、继续解析不会像有些同步工具那样直接卡死源库。运维排查时也很方便延迟发生在哪一段看进程状态和队列积压量就知道了。部署时不要图省事把三套东西塞在一台机器上至少要保证捕获进程和应用进程在不同服务器否则目标库负载一高反过来拖慢日志解析两边的活全堵在一起。2.3 部署前先问自己三个问题带宽、时延、异构兼容我一般接到同步需求会先问三个问题这三个问题直接决定部署方案要不要加减组件。第一个问题是带宽够不够。同步的数据量不是按业务平均流量算的而是按峰值算的。曾经有个项目源库是大促场景白天流量一般晚上定时任务一跑一个小时产生 20GB 日志网络带宽只有 50Mbps结果增量延迟从几分钟一路涨到几个小时。这种情况单靠调参数救不回来得加带宽或者把传输压缩打开在部署时就预留好余量。第二个问题是时延要求有多高。如果业务方说“实时同步”实际容忍 5 秒还是 500 毫秒部署重点完全不一样。要求低可以适当加大批量提交参数吞吐优先要求高就要减少批处理大小、提高轮询频率同时接受目标库压力变大。第三个问题是异构兼容。Oracle 同步到 Oracle和 Oracle 同步到达梦能用的功能范围差别很大。比如目标库不支持某种数据类型或 DDL 语法同步任务就会频繁出错。部署前的做法是把源库的字段类型清单拉出来和目标库方言对一遍把风险列成表比上线后一个一个踩要省太多时间。2.4 部署规划表先画拓扑再动手装这里给出一张我每次部署前都会画的规划表照着填完再动手能避免大量返工。项目必填内容说明源库信息数据库类型、版本、IP、端口、SID/服务名SQL Server 要确认实例名达梦要确认模式和口令目标库信息数据库类型、版本、IP、端口、字符集异构同步尤其要确认字符集和排序规则同步范围schema/库名、表清单、过滤条件多对一汇聚要确认表名冲突怎么办网络情况源到目标带宽、是否有防火墙尽量同机房部署捕获进程账号权限源库同步账号、目标库同步账号建议单独建号不用 dba 账号日志策略源库归档保留天数、归档空间上限决定同步中断后还能找回多少数据3. 部署前置检查源库打补丁、开归档、养账号3.1 开启归档和最小补充日志三条 SQL 别跳过RealSync 的日志捕获依赖源库的在线日志和归档日志所以源库必须处于归档模式。很多第一次部署的人在这步翻车业务库里日志模式是 NOARCHIVELOG捕获进程一起动就报找不到日志还以为是工具坏了。用下面这几条命令先把源库的底子打好。-- 检查源库是否开启归档 SELECT log_mode FROM v$database; -- 结果 ARCHIVELOG 才是正常的NOARCHIVELOG 要先改库 -- 开启最小补充日志关键步骤不开启会导致部分字段变更解析不到 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 开启主键补充日志同步时才能按主键精确更新 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;第一句是体检Log mode 只有是 ARCHIVELOG 才能继续。第二句是最小补充日志这一步的作用是让源库把变更涉及的字段信息全部写进日志不开启的话同步工具解析出来的 UPDATE 语句可能只带主键和变更字段缺了其他列目标库重放时就出问题。第三句是主键补充日志按主键定位数据行必须有它。这三条必须按顺序执行完然后重启数据库让它生效。注意执行完要再查一遍确认不要凭印象觉得开过了。3.2 同步账号授权缺一个查询权限就是黑匣子源库的同步账号权限给少了捕获进程不会直接报“权限不足”而是表现得很诡异启动正常日志也读出来了就是同步过来数据不对或者某些表一直不动。这是因为日志解析过程中要用到数据字典来翻译表名、字段名和类型数据字典相关信息在被 V$ 视图或 DBA 视图挡住时就静默失败。我常用的授权脚本是这一套按需调整别直接给 DBA。-- 创建同步账号 CREATE USER sync_user IDENTIFIED BY StrongPass_2024; -- 授权连接和资源 GRANT CONNECT, RESOURCE TO sync_user; -- 授权读取数据字典视图捕获进程翻译日志必需 GRANT SELECT ANY DICTIONARY TO sync_user; GRANT SELECT ON DBA_LOG_GROUP_COLUMNS TO sync_user; -- 授权读取业务表数据初始化装载阶段用 GRANT SELECT ANY TABLE TO sync_user;权限给到 SELECT ANY DICTIONARY 和 SELECT ANY TABLE基本能覆盖日志解析和初始化装载两个阶段的读取需求。不需要 UPDATE 或 DELETE 权限RealSync 是纯读取源库这点很多安全审计的人会问。目标库那侧反而是要建一个能建表、能增删改的账号权限要求比源库高很多。曾经遇到一个项目源库同步账号权限齐全但目标库账号只给了 CONNECT结果每张表创建都失败看日志还看不出个所以然来。记住一句话源库给读权限目标库给写权限两边不要搞混。3.3 网络与时钟两个容易被忽略的硬约束网络和时钟这两个事部署手册里通常只有一两句话但往往是上线后最难排查的故障源。网络方面最容易被忽略的是防火墙对长连接的限制。RealSync 的捕获进程和目标端进程之间是长连接很多防火墙策略默认空闲 30 分钟或 1 小时就断开导致同步链路看似正常实际上早已断开。解决办法是在部署前跟网络管理员确认源到目标方向的 TCP 长连接不做空闲断开或者开启 keepalive。部署时也要测试跨网络的端口连通性telnet 一下端口比什么都实在。时钟方面捕获进程解析日志时会给每个事务打上时间戳目标端重放时也依赖这个时间戳来排序。源库和目标库服务器时间差太大会导致两个问题事务顺序乱掉、监控面板上的延迟是负数或巨大正数。部署时统一用 NTP 校准所有服务器时间差距控制在秒级以内。曾经有个项目源库服务器时间快了 10 分钟做数据校验时永远对不上最后排查半天发现是时钟问题。不要觉得这是小事分布式环境里时钟就是玄学之王。4. 安装与首次同步从进程管理软件到初始化装载4.1 安装进程管理软件和核心组件目录规划建议RealSync 的安装包解压后核心组件就是进程管理软件和两个执行组件。我在多次部署中形成了一套固定的目录规划习惯能省掉很多后期找日志的麻烦。/opt/realync/ ├── manager/ # 进程管理软件负责启停各业务进程 ├── capture/ # 采集端程序及配置 ├── receiver/ # 接收端程序及配置 ├── logs/ # 所有进程日志统一软链接到这里 ├── data/ # 本地队列和缓存数据预留大空间 └── backup/ # 配置文件备份这套目录结构的好处是各组件独立、方便定位。安装顺序上先装进程管理软件再把采集端和接收端分别部署到源和目标服务器。环境变量要提前配好特别是 JAVA_HOME 或者依赖的系统库路径否则启动时候报找不到类或共享库一查全是环境问题而不是产品问题。安装完成后进程管理软件启动起来用自带的检查命令看所有服务是否注册成功不要跳过这一步直接配置同步任务。4.2 配置数据源与同步任务dsc 的参数怎么填接下来是配置数据源连接信息。RealSync 的配置方式是用一组数据源配置文件描述源库和目标库的连接信息同步任务则在另一组配置里定义。这里以常见的数据源配置段为例关键参数直接对标。source_db { db_type oracle ip 192.168.10.10 port 1521 service_name ORCL username sync_user password encrypted_string } target_db { db_type dm8 ip 192.168.10.20 port 5236 schema SYNC_SCHEMA username sync_user password encrypted_string char_set UTF-8 }db_type 决定了解析和重放逻辑走哪套方言不能填错。service_name 对于 Oracle 来说要确认是 SID 还是服务名填错连不上。密码这里用加密串不要裸传明文安装包里一般自带加密工具。char_set 这一项是异构同步的命门源库是 ZHS16GBK、目标库是 UTF-8 时字符转换按哪个映射表走必须明确否则中文乱码会从数据本身一路蔓延到日志。第一次配置完使用连接测试功能验证一下别省这一步。同步任务的配置里关键参数是同步范围、映射关系、过滤条件。一张表到一张表的映射很简单多张源表汇聚到一张目标表时要注意主键冲突这时要在任务里显式配置各源表的业务主键映射。过滤条件支持按字段值过滤比如只同步 status1 的行配置后可以用源库一条查询验证过滤结果避免同步了一堆不需要的数据。4.3 初始化装载与增量启动先全量后增量的正确顺序首次同步的正确顺序是先做全量初始化再做增量。顺序反了会有一个经典问题全量装载跑完需要两小时这两小时内的增量日志已经积压启动增量时要做日志拼接追平的时间取决于日志积压量。最稳妥的流程是这样第一步在源端记录当前日志时间点。第二步启动全量初始化装载工具把源库现有数据按表结构搬过去。第三步全量跑完校验目标库行数和源库一致确认没有漏表漏数据。第四步启动增量捕获和重放进程从刚才记录的时间点开始追增量追平后进入准实时状态。# 典型的启动顺序先启动进程管理软件再启动业务进程 cd /opt/realync/manager bin/start_manager.sh # 查看进程状态确认采集端和接收端都在线 bin/show_status.sh启动完成后用数据库自带的方式做一次快速核对源库和目标库各跑一条 count 语句对关键大表看行数是否一致。初始化装载阶段最常见的坑是源库表正在被业务频繁修改导致全量读到的数据和日志解析出的增量重叠或遗漏。解决方法是初始化期间配合业务方做一次静默窗口或者依赖工具自身的一致性快照机制。这个窗口哪怕只有 10 分钟也能避免事后对数据时头大。5. 部署和运维避坑四个场景让我翻过车5.1 现象一捕获进程起来就退出现象进程管理软件里看到采集端进程启动后几秒就退出或者反复重启日志文件里没有明显的报错信息。原因最常见的情况是源库日志模式没开归档或者同步账号缺失数据字典读取权限。捕获进程启动时会预检源库环境预检不通过就自动退出但这个退出的提示不一定写在显眼位置需要翻详细日志才能看到。解决先查源库 log_mode 是否为 ARCHIVELOG再查同步账号权限最后看采集端配置里的连接信息。三步走完90% 的启动失败都能解决。不要一上来就怀疑安装包坏了重装解决不了环境问题。5.2 现象二增量同步延迟越拉越大现象监控面板上同步延迟从几秒涨到几分钟再涨到几十分钟目标端数据越来越旧。原因延迟暴涨分两种情况。一种是源库在跑大事务或批量任务日志量瞬间暴增而目标端应用进程是单线程或线程数不足处理不过来。另一种是目标库锁等待应用进程在重放一条 DML 时被业务查询堵住后续事务全部排队。解决针对大事务把事务拆小是源头方案针对单线程瓶颈调大接收端并发线程数从默认值逐步上调。针对锁等待要看目标库侧的业务空闲窗口把同步重放和业务高峰错峰。排查延迟问题时先看是捕获端延迟还是接收端延迟捕获两端口径不一样处理方案完全不同。5.3 现象三目标库数据对不上现象数据校验发现目标库某些行和源库不一致有的多出来、有的少掉、有的字段值不同。原因一大半是源库表缺少主键或唯一索引。逻辑复制按主键定位数据行没有主键的表重放 UPDATE 和 DELETE 时定位不到唯一行更新结果就会错乱。另一小半是初始化装载和增量启动之间的窗口期没处理好数据重叠或遗漏。解决部署前就要求源库所有同步表必须主键没有主键的和业务方确认是否跳过该表不能用行号或全字段匹配来做无主键同步那是拿数据一致性赌运气。窗口期问题的话初始化装载时记录好日志位点启动增量前再校准一次必要时把相关表在窗口期满后重新比对一次。5.4 现象四磁盘告警和归档堆积现象源库服务器的磁盘空间告警归档日志目录不断增长同步中断后重启发现无法从上次的位点续传只能重做初始化。原因同步中断期间源库归档日志没有清理机制或清理策略被同步需求挡住归档文件一直堆积。磁盘满后源库数据库本身也可能挂掉损失就大了。解决同步中断后要尽快处理不要拖。恢复前先确认归档日志保留的天数是否覆盖了中断时间范围。如果中断超过保留期限老老实实重新做初始化装载不要试图强行续传。日常运维时要对源库归档目录做空间监控阈值设到 70% 就要告警不能等到 90% 才看。同步进程稳定后可以考虑让清理归档的任务跳过同步所需的日志段但前提是同步中断的时间窗口能兜底。6. 上线后的验证与进阶技巧把部署手册变成运维速查表6.1 从“部署完成”到“同步正常”的四个验证口径部署完成不等于同步正常我每次上线都会按四个口径逐级验证。第一个口径是进程状态采集端和接收端都在运行没有反复重启。第二个口径是延迟时间源库提交一条测试数据在目标库几秒内能看到这条最常见也最直观。第三个口径是行数一致抽 3 到 5 张大表做 count 比对大表和小表都要覆盖到。第四个口径是数据内容准确抽几条新增和修改的数据逐字段比对值这步能发现字符集和数据类型转换问题。四步走完才能把同步任务交给业务方验收。6.2 参数调优方向常见调参顺序与验证方法同步上线跑一周后就要看监控数据调优了。我习惯先调接收端并发线程数再调传输批量大小最后才动捕获端的读取频率。每调一个参数都要记录原值和调整后的表现不要一次动好几个参数否则出了问题都不知道哪步引起的。调参验证的方法很简单制造一段峰值日志流量观察延迟曲线的尖峰是不是明显下降没有变化就调回原值。参数不是越大越好并发线程数过高会导致目标库连接数暴涨拖慢正常业务。6.3 用数据核对脚本守住日常一致性最后分享一个我常用的数据核对脚本思路。每周跑一次抽取式校验定时抽查若干张核心表对比源端和目标端的 rowid 映射数据是否一致。不需要全表对比核心业务表覆盖到就够了。脚本逻辑不复杂就是按主键拉取源端和目标端的字段拼接哈希值不一致的记录下来入告警。这个脚本投入使用后帮我抓出过两次字符集边界问题。回头翻《迪思杰 RealSync 部署手册.doc》里面其实都写了这些点但没踩过坑的人很难一次到位。部署本身不难难的是部署前想清楚架构、部署后盯住细节把这份文档当成活文档不断往里补自己项目的坑希望帮到你。本文还有配套的精品资源点击获取