简介迪思杰RealSync部署手册面向数据库运维人员与系统集成工程师聚焦Oracle环境下数据复制软件的安装与配置帮助读者在源端与目标端完成RealSync的完整部署。手册以doc文档形式呈现压缩包内共1个文件大小约129KB内容按源端、目标端及系统参数设置三大模块组织涵盖创建操作系统用户与数据库用户、创建数据库视图、登陆系统主机、安装RealSync软件、启动Agent与Dbpsd等关键步骤并给出注册主机和数据库信息、配置同步内容、发起首次同步的操作指引。目录层级清晰步骤编号明确便于按序查阅与落地实施。目前已有128人学习下载适合需要快速掌握RealSync复制软件部署流程、对照排查安装配置问题的技术人员参考使用。1. 迪思杰 RealSync 部署手册从零搭起一套异构数据库实时同步链路第一次接触迪思杰 RealSync 的人多半是被一个具体需求推着来的生产库是 Oracle报表库想换成 MySQL 或者达梦业务不能停数据延迟还得压到秒级。这时候翻到一份《迪思杰 RealSync 部署手册.doc》标题看着简单真正落地时才发现里面藏着源端抽取、目标端装载、网络链路、字符集、DDL 同步一大堆细节。RealSync 是迪思杰DSG做异构数据库实时复制的一套工具核心思路是在源库侧捕获增量日志经过解析、转换后投递到目标库实现准实时的数据同步。它适合的场景很明确跨数据库类型、跨操作系统、要求低延迟且不能大改现有业务系统的数据集成项目。这篇笔记不照搬手册目录而是按一线部署顺序把环境准备、参数配置、启动验证和踩坑排查讲清楚让新手能照着走熟手能对参数边界心里有数。2. 部署前必须想清楚的选型与环境账2.1 RealSync 到底解决哪类同步问题先把定位说清楚不然后面参数全是玄学。RealSync 属于基于日志的增量复制工具和基于触发器、基于时间戳轮询的方案比它对源库性能影响小延迟低能拿到变更的完整前后镜像。和同类的 Oracle GoldenGate、阿里 DTS 比它的差异点在于对国产数据库和异构组合的支持更贴国内项目实际比如 Oracle 到达梦、Oracle 到 MySQL、DB2 到 Oracle 这类组合。选它之前先确认三件事源库是否开启了归档或补充日志、目标库的写入权限是否给全、网络是否允许源端和目标端之间稳定通信。这三条任何一条不满足后面部署都会卡住。常见做法是先做一次全量初始化再用增量追平。全量阶段用导出导入或者工具自带初始化增量阶段靠日志捕获。很多人一上来就配增量结果目标库是空的同步跑起来全是 update 找不到记录这就是顺序错了。2.2 源端与目标端的硬性检查清单部署前把下面这张表逐项过一遍比事后排错省事得多。检查项源端要求目标端要求数据库版本确认在 RealSync 支持矩阵内同样确认支持矩阵日志模式Oracle 需归档补充日志无特殊要求账号权限读取日志、查询字典视图建表、增删改、DDL 权限字符集记录源库字符集目标库字符集需兼容或可转换网络到目标端端口可达到源端端口可达磁盘日志保留空间充足数据文件空间按增量预估补充日志这条最容易翻车。Oracle 默认只记录部分列RealSync 要拿到完整行镜像必须开ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;对关键表还要加ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS。不开的话同步过去的 update 只有主键没有其他列目标端数据就是错的。2.3 安装包与依赖的落地准备拿到安装介质后先确认操作系统位数、glibc 版本、JDK 版本。RealSync 服务端一般跑在 Linux 上管理控制台可能是 Java 客户端。部署顺序通常是先装服务端再配源端和目标端的连接信息最后在控制台里建同步任务。安装目录别放系统盘日志增长比想象中快。依赖方面确认libaio、unzip这些基础包在Oracle 客户端或对应数据库驱动要提前装好否则连不上库。提示安装前把源库和目标库的时区、NTP 对齐时间不一致会让延迟统计和日志定位出现偏差。3. 一步步把 RealSync 服务端和同步任务跑起来3.1 服务端安装与初始化假设安装包解压到/opt/dsg/realsync用专用账号运行不要用 root 直接跑服务。下面是一段典型的初始化命令流程。# 创建专用用户和目录 useradd -m dsguser mkdir -p /opt/dsg/realsync chown -R dsguser:dsguser /opt/dsg # 解压安装包 su - dsguser cd /opt/dsg unzip RealSync_Server_x.x.x.zip -d /opt/dsg/realsync # 执行安装脚本按提示指定安装路径和端口 cd /opt/dsg/realsync ./install.sh安装脚本会问安装路径、管理端口、日志路径。管理端口默认常见是 8xxx 段冲突就换。安装完成后会生成服务启动脚本一般在bin目录下。逻辑说明专用用户是为了权限隔离避免服务进程拿到过高系统权限单独目录是为了后续升级和日志清理方便。参数上日志路径建议单独挂盘保留天数按增量量估算别用默认的 7 天生产环境往往要留 30 天以上做回溯。3.2 配置源端和目标端连接服务端起来后进管理控制台配置数据库连接。源端要填主机、端口、实例名、账号密码还要指定日志读取方式。目标端填连接信息即可。配置时注意账号密码里如果有特殊字符在配置文件里要转义否则解析失败。# 启动服务端 cd /opt/dsg/realsync/bin ./start.sh # 查看服务状态和端口监听 netstat -tlnp | grep 8xxx tail -f ../log/realsync.log启动后先看日志有没有报连接失败、驱动缺失。常见报错是ORA-01031: insufficient privileges说明源端账号权限不够补上SELECT ANY DICTIONARY、SELECT ANY TRANSACTION这类权限。目标端如果报字符集不匹配要么改目标库字符集要么在任务里配转换规则。3.3 建同步任务的参数怎么设建任务时几个关键参数决定同步行为。同步类型选全量增量冲突处理策略选覆盖或忽略按业务定批量提交大小影响性能和延迟一般 500 到 2000 行一批DDL 同步开关看目标端能不能接受结构变更生产上建议先关手动评审后再开。-- 源端 Oracle 开启补充日志这是增量同步的前提 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; -- 确认补充日志状态 SELECT supplemental_log_data_min, supplemental_log_data_all FROM v$database;逻辑说明第一条开启最小补充日志第二条对全列记录镜像。查询返回 YES 才算生效。参数上ALL COLUMNS会增加日志量磁盘要留够。如果只对部分表同步可以只对这些表加补充日志减少开销。3.4 启动同步并做第一轮验证任务建好后先别急着上生产拿一张测试表验证。在源端插入、更新、删除各一条看目标端是否在秒级内一致。# 源端执行 INSERT INTO test_sync(id, name) VALUES (1, a); UPDATE test_sync SET name b WHERE id 1; DELETE FROM test_sync WHERE id 1; # 目标端查询确认 SELECT * FROM test_sync WHERE id 1;验证顺序是先看任务状态是否 running再看延迟指标最后比对数据。延迟指标在控制台能看到如果一直增长说明追不上要调批量大小或检查网络。数据比对建议用行数和校验和别只看几条记录。第一轮验证通过后再逐步加表别一次性全库上。4. 部署中最容易翻车的几个点4.1 补充日志没开全导致 update 丢列现象目标端 update 后只有主键变了其他列还是旧值。原因源端只开了最小补充日志日志里没有完整行镜像。解决对相关表执行ALTER TABLE xxx ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;然后重启同步任务重新初始化。这个坑血泪经验最多很多人以为是工具 bug其实是日志没配全。4.2 字符集不一致导致中文乱码现象目标端中文变成问号或乱码。原因源端和目标端字符集不同且没配转换。解决先确认两边字符集SELECT * FROM nls_database_parameters WHERE parameter NLS_CHARACTERSET;能统一就统一不能统一就在任务里配字符集映射。注意 UTF8 和 AL32UTF8 不是一回事别混。4.3 大事务导致延迟飙升现象源端跑了一个百万行的事务目标端延迟从秒级涨到几十分钟。原因RealSync 按事务提交才投递大事务要等提交后才开始传。解决业务上拆大事务或者调大批量提交参数同时确认网络带宽够。这个没有银弹只能从业务侧配合。4.4 目标端主键冲突导致任务中断现象任务报 duplicate key然后停了。原因全量初始化时目标端已有数据或者增量重放顺序问题。解决初始化前清空目标表或者配冲突策略为覆盖。任务中断后要看日志定位到具体表处理完再重启别直接忽略。4.5 网络抖动导致连接断开不自动重连现象任务状态变成 disconnected数据不再同步。原因网络不稳定或者防火墙断了长连接。解决配心跳和自动重连参数防火墙放行长连接。生产环境建议源端和目标端之间走专线或稳定内网别跨公网。5. 把同步链路做稳的几个进阶习惯部署跑通只是开始真正难的是长期稳定。我一般会做三件事。第一建监控盯延迟、任务状态、日志错误关键字延迟超过阈值就告警。第二定期做数据比对不用全库抽核心表按行数和校验和比发现漂移早处理。第三保留后悔药源端归档日志别删太早目标端定期备份出问题能回溯。验证同步是否真正可靠可以做一个反向校验脚本定期在源端和目标端跑同样的聚合查询比对结果。-- 源端和目标端分别执行比对结果 SELECT COUNT(*) AS cnt, SUM(amount) AS total FROM orders WHERE create_time SYSDATE - 1;两边结果一致才算同步正常。参数上比对频率按业务敏感度定核心表可以每小时一次非核心每天一次。这个习惯能帮你提前发现很多隐性不一致比等业务报障强。最后一个技巧是版本升级和补丁。RealSync 不同版本对数据库版本支持不一样升级前先在测试环境验证别直接在生产上打补丁。升级前备份配置文件和任务定义出问题能快速回滚。我自己就吃过没备份配置的亏重配任务花了大半天。希望帮到你。本文还有配套的精品资源点击获取