简介DSG RealSync复制系统安装配置手册是一份由迪思杰北京数码技术有限公司提供的官方技术文档面向软件开发、数据库运维及数据同步项目实施人员重点解决跨服务器数据库之间的实时/定时数据复制与一致性保障问题。资源为单个PDF文件大小约1.19MB内容严格遵循实际部署流程展开先介绍源端和目标数据库服务器上的安装前准备包括操作系统兼容性检查、系统用户/目录/视图创建、内存与磁盘空间确认再逐步讲解RealSync复制软件安装、启动脚本配置、Agent与Dbpsd进程启动及日志查看随后说明如何注册主机与数据库信息、验证配置、建立数据表映射关系并启动复制同时给出首次同步后的监控与异常处理要点。全手册以分步操作注意事项形式呈现既能指导初次使用者从零搭建环境也可作为已有系统运维时的排错参考。目前已有62人学习适合需要快速掌握DSG RealSync同步方案的技术人员直接对照使用。1. DSGRealSync是什么为什么数据库同步老出问题的团队都在用它一说到跨库实时同步Oracle DataGuard 能做容灾但要同步到 MySQL、Hadoop、HBase 或者异地 Oracle很多团队第一反应就是 DSGRealSync 复制系统。它核心的思路很简单解析源端 redo 和归档日志里的增量事务按业务规则投递到目标端不依赖源库触发器也不要求业务表上有时间戳字段。我最近帮一个客户从零部署了一套从 JDK 环境、Oracle 客户端到采集端、装载端配置完整走了一遍。这篇按我实际落地的顺序来讲装前准备、安装步骤、参数调优、验证方法最后集中讲几条让我翻过车的避坑记录。适合正在做数据库同步选型、或者拿到安装包不知道怎么下手的运维和 DBA 参考。2. 装前准备JDK、数据库客户端与操作系统边界条件很多同步链路装到一半失败问题不在 DSGRealSync 本身而在最基础的环境边界没守住。我在部署前会花小半天把 JDK、数据库客户端、账号权限和端口全部核对一遍后面配置采集端和装载端时基本不会再来回折腾。2.1 安装 JDK 并设置环境变量决定复制进程能不能启动的第一步DSGRealSync 的采集、装载、管理控制台都是 Java 进程所以 jdk 安装及配置教程里讲的那些坑在这里一个不落。我这边推荐把 JDK 版本固定在 1.8不要追新。很多同步组件编译时基于 JDK 8换成 OpenJDK 11 或 17 之后启动阶段经常直接报UnsupportedClassVersionError看着像是软件坏了其实是你 JDK 版本不对。# 安装JDK 8以CentOS 7环境为例 tar -zxvf jdk-8u202-linux-x64.tar.gz -C /usr/local/ mv /usr/local/jdk1.8.0_202 /usr/local/jdk8 # 写入全局环境变量不要只 export 在当前 shell cat /etc/profile EOF export JAVA_HOME/usr/local/jdk8 export JRE_HOME$JAVA_HOME/jre export CLASSPATH.:$JAVA_HOME/lib:$JRE_HOME/lib export PATH$JAVA_HOME/bin:$PATH EOF # 生效并验证 source /etc/profile java -version逻辑说明写入/etc/profile是为了保证你用脚本或 systemd 启动 DSGRealSync 时也能拿到JAVA_HOME只敲一行临时 export 的后果就是重启后进程起不来日志里报java: command not found。验证时看输出里必须是1.8.x如果是 openjdk 版本号 11 或更高就得重新装。参数说明CLASSPATH里的.代表当前目录同步组件在运行时可能会加载同目录下的配置或扩展包这一步别省如果你要为管理控制台单独设 JVM 内存可以在启动脚本里加JAVA_OPTS-Xms1g -Xmx2g具体大小按你的同步数据量和机器内存调整一般 2G 起步。2.2 数据库客户端与源/目标端连通性检查最容易被跳过的黑匣子DSGRealSync 在源端连接 Oracle 时通常走的是 OCI 方式也就是说目标机器上必须有一套能和 Oracle 版本匹配的客户端库这经常是个黑匣子你配置写对了启动还是报无法加载驱动。我习惯先装 Oracle Instant Client并确认 sqlplus 能连上源库再开始配同步。# 配置 oracle client 环境变量 export ORACLE_HOME/usr/local/instantclient_19_18 export LD_LIBRARY_PATH$ORACLE_HOME:$LD_LIBRARY_PATH export PATH$ORACLE_HOME:$PATH # 用 sqlplus 确认源库连通 sqlplus dsg_user/Passw0rd//192.168.10.20:1521/ORCLPDB1 # 用 tnsping 检查网络和监听 tnsping ORCLPDB1逻辑说明sqlplus能连上只代表网络、监听、账号密码都没问题不代表同步软件能调起 OCI 接口还要确认libclntsh.so能在LD_LIBRARY_PATH里被找到这一步放到后面的避坑章节细说。源库如果是 Oracle 12c 以后的 PDB连接串里建议写 service_name写 SID 容易连到 CDB 上去权限模型完全不一样。参数说明LD_LIBRARY_PATH要放在启动 DSG 进程的同一个用户环境里我一般直接写进/home/syncuser/.bash_profile避免手工 export 漏掉。目标端如果是 MySQL就把mysql -h连通性先跑一遍如果是 SQL Server至少用 sqlcmd 执行一条SELECT 1这类检查花不了十分钟能省下后面大量排错时间。2.3 操作系统账号、文件权限与端口规划很多团队图省事直接拿 root 跑同步一旦采集端或装载端异常退出会在 root 家目录下留下一堆日志和临时文件而且权限过大时配置文件写错一个路径就可能把系统目录搞乱。我一般会建一个独立账号syncuser把所有同步组件和数据文件都归到这个账号下。用途端口说明管理控制台 Web8443浏览器访问控制台查看链路状态采集端到装载端数据流7880两端进程之间的传输通道节点状态心跳7881各节点代理向控制台上报状态参数说明上面三个端口是我在项目里的常见规划不同版本安装包默认值可能不一样具体以你拿到的安装说明为准。规划端口时要注意两点一是不要和已有业务的端口冲突二是防火墙里要把这三类端口都放通很多控制台显示节点离线原因不是服务挂了而是 7881 心跳端口被防火墙挡了。目录权限方面我建议把队列、日志和安装目录分开。比如用/data/dsg/app放程序/data/dsg/queue放待投递数据/data/dsg/log放运行日志然后chown -R syncuser:syncgrp /data/dsg。队列目录尽量不要和系统根分区放一起同步高峰时队列文件增长很快根分区写满的后果是整个操作系统进入只读状态这是我在生产环境见过最严重的翻车现场之一。3. 安装DSGRealSync的完整步骤从解压到链路启动环境就绪后正式安装分四步解压划分目录、配置采集端、配置装载端、启动控制台并拉起链路。下面按顺序走每一节都给了可以直接抄的配置片段。3.1 解压安装包并划分目录结构组件各自归位安装包解压后不要一股脑全扔到/optDSGRealSync 按职责大概分三块采集端负责读日志装载端负责写目标库控制台负责监控管理。我习惯在/data/dsg下建好分目录结构再按模块拷贝。# 建立标准目录结构 mkdir -p /data/dsg/{capture,apply,console,log,conf,bin,queue} tar -zxvf DSGRealSync_Install.tar.gz -C /tmp/dsg_pkg # 分模块拷贝便于后续单独升级或排查 cp -r /tmp/dsg_pkg/capture/* /data/dsg/capture/ cp -r /tmp/dsg_pkg/apply/* /data/dsg/apply/ cp -r /tmp/dsg_pkg/console/* /data/dsg/console/ # 配置和日志单独管理 cp /tmp/dsg_pkg/conf/*.ini /data/dsg/conf/ chown -R syncuser:syncgrp /data/dsg逻辑说明分目录管理最大的好处是出问题时定位快。采集端日志异常直接看/data/dsg/log下对应模块文件不用在一个大目录里翻。队列目录单独建也是这个原因它能反映链路是否堆积如果这个目录瞬时占用暴涨说明装载端写入跟不上采集端的读取速度。参数说明/tmp/dsg_pkg是临时解压目录安装完成后可以删掉避免占用磁盘空间。syncuser和syncgrp是你在上一章创建的账号和用户组确保后续进程以普通用户运行。如果你的安装包是分卷压缩格式解压时要先合并分卷再解压不要手动拼接文件名。3.2 配置采集端 Capture连接源库与归档日志的入口采集端是整个同步系统最核心的模块它的任务是从源库日志里拉出增量事务。配置文件里最不能出错的就是源库连接信息和日志获取方式。下面是一份我在 Oracle 源端常用的采集配置[SOURCE] db_typeORACLE db_userdsg_user db_passwordEncrypted123 db_host192.168.10.20 db_port1521 db_serviceORCLPDB1 archive_modeARCHIVELOG mining_logREDO_ARCHIVE [QUEUE] queue_dir/data/dsg/queue queue_size4096 [SYNC] timeout_sec60 retry_times5逻辑说明db_user是源库独立建的同步账号不要直接拿SYS或SYSTEM用生产环境权限控制严格独立账号便于审计和回收权限。archive_modeARCHIVELOG表示源库必须运行在归档模式下如果源库是非归档模式采集端读不到历史日志链路根本起不来。mining_logREDO_ARCHIVE表示同时使用在线 redo 和归档日志这是最常见的配置方式保证日志切换瞬间事务不丢。参数说明queue_size单位是 MB表示采集端内存队列的上限。同步大事务时如果这个值设得太小比如 512采集端会出现频繁等待设得太大又占用 JVM 内存。我一般按同步表数量估算表多就 4096表少可以降到 1024。timeout_sec和retry_times是采集端与源库之间的连接超时和重试次数网络抖动频繁的环境可以把超时提高但重试次数不建议超过 10 次否则源库异常时采集端会一直挂着不报错。你还需要在源库给dsg_user授相关的日志读取权限。不同 Oracle 版本授权略有差异核心是允许该账号访问事务日志信息。我一般会执行下面的授权语句GRANT CONNECT, RESOURCE TO dsg_user; GRANT SELECT ANY TRANSACTION TO dsg_user; GRANT EXECUTE ON DBMS_LOGMNR TO dsg_user;这里DBMS_LOGMNR是 Oracle 日志挖掘包DSGRealSync 在采集端要借助它解析 redo 内容。如果授权不全启动时通常不会立刻报错而是源库产生一定量日志后采集端突然停止日志里出现权限错误这个坑比较隐蔽。3.3 配置装载端 Apply目标端连接与写入方式装载端负责把采集端传过来的事务落到目标库。它的配置核心是目标库连接、写入并发和错误事务处理策略[TARGET] db_typeORACLE db_userdsg_target db_passwordEncrypted456 db_host192.168.10.30 db_port1521 db_serviceORCLTGT sync_modeCE mapping_file/data/dsg/conf/mapping_rule.xml [TXN] commit_batch500 write_threads4 error_log/data/dsg/log/error_txn.log逻辑说明sync_modeCE是提交等价模式意思是目标端事务的提交顺序尽量与源端保持一致保证数据最终一致性。如果业务允许最终一致可以考虑sync_modeASYNC提高吞吐但这会导致目标端事务顺序和源端不完全一致配置前一定要和业务方确认。mapping_file指向表映射和过滤规则文件这个文件路径要保证装载端进程有读权限。参数说明commit_batch是攒多少条记录批量提交一次。值越大单次提交耗时越长但整体吞吐更高。我经验是源端大事务较多时先设 500 观察目标库压力CPU 空闲可以逐步调大到 1000如果目标库出现锁等待就要调小。write_threads是写入线程数一般不超过目标库 CPU 核数设太大会导致目标库出现大量并发会话反而引起行锁竞争。3.4 初始化链路并启动管理控制台配置都准备好后按顺序启动。顺序最好不要颠倒先把控制台拉起来再启动采集端最后启动装载端这样装载端启动时如果有历史积压数据管道已经就绪。cd /data/dsg/bin # 启动管理控制台 ./dsg_console start # 启动采集端 ./dsg_capture start --conf /data/dsg/conf/real_sync_capture.ini # 启动装载端 ./dsg_apply start --conf /data/dsg/conf/real_sync_apply.ini # 查看各节点状态 ./dsg_status all逻辑说明--conf参数指向各自的配置文件如果你在同一台机器上部署了多套同步链路必须用不同的配置文件启动多个实例否则进程会互相覆盖状态文件。dsg_status all会输出采集端、装载端、控制台的状态和当前 SCN 位置顺手敲这一条能确认三个进程都起来了。启动完成后打开浏览器访问https://服务器IP:8443控制台里能看到采集端和装载端的连接状态、当前延迟秒数、最近同步的表记录数。到这里一条最基础的复制链路已经建立接下来要处理的就是让它稳定跑起来的那些参数。4. 复制链路参数调优与链路验证日志挖掘、过滤规则与断点续传链路能启动只说明配置格式没错不代表它能稳定顶着生产流量跑。参数调优的目标是控制延迟、减少无效同步、保证异常恢复后不丢数据。这一章讲日志挖掘、过滤规则和验证方法。4.1 日志挖掘参数与归档策略的关系使用 DSGRealSync 最大的前置条件是源库开启归档模式。采集端要从归档日志里读历史事务如果源库归档保留时间太短采集端一旦断链超过保留窗口就再也追不上只能重新初始化数据。这个问题的根源不在 DSG而在源库策略。-- 源库开启归档并设置保留空间 alter system set log_archive_dest_1location/oracle/arch scopeboth; alter system set db_recovery_file_dest_size512G scopeboth; alter database archivelog;逻辑说明log_archive_dest_1指定归档日志存放位置这个目录的磁盘空间要提前规划至少能容纳两天的日志量。db_recovery_file_dest_size是快速恢复区的大小上限如果源库还有 DataGuard这个值要根据备库的归档拉取速度调整否则恢复区写满后源库会直接 hang 住。DSGRealSync 的采集端从 redo 和归档中读取日志时有一个比较关键的状态叫当前挖掘 SCN。控制台上如果看到源库最新 SCN 和采集 SCN 差值持续增大优先检查归档是否连续、归档目录是否可读。我见过有运维为了省磁盘空间定时删除三天前的归档结果同步链路一夜之间落后十几个小时这种操作一定要在确认采集端已经消费完对应日志后再做。4.2 DML/DDL 同步过滤与表映射规则生产库通常有成百上千张表但真正需要同步的可能只有几张核心业务表。全量同步不仅浪费带宽还会把一些日志表、临时表的数据也带到目标库导致目标库存储压力剧增。我一般在 mapping 文件里用白名单方式放行业务表mapping table sourceSCOTT.ORDERS targetBIZ.ORDERS / table sourceSCOTT.CUSTOMER targetBIZ.CUSTOMER conditionREGIONCN / ignore-table sourceSCOTT.TEMP_* / /mapping逻辑说明source是源库表名target是目标库表名两个名字不一致时配置在这里。condition是行级过滤条件只同步满足条件的记录这个功能很实用比如只同步国内区域数据可以大幅减少传输量。ignore-table支持通配符用来跳过临时表避免把中间计算数据同步过去。DDL 同步要分情况对待。表结构变更如果你的业务经常加字段建议开启 DDL 同步并配置自动映射字段名如果目标库结构由专人管理我更推荐关闭 DDL 同步否则源端一条DROP TABLE可能把目标表直接删了。DSGRealSync 控制台里一般有 DDL 策略选项按环境选择即可没有绝对的对错。4.3 复制链路验证方法从日志解析到数据比对参数调完不能只看进程活着就结束我会做三件事验证链路真在干活。第一件看采集端日志里最新解析到的 SCN 或日志序列号是否持续增长。如果数字一直不动说明源库没有新日志产生或者采集端已经断链控制台状态不可信时日志是最直接的依据。第二件在源库随便找一张已配置同步的表执行一条 UPDATE然后立刻到目标库查这条记录。这里注意不要用COMMIT后立刻查极小概率会有几秒延迟等待 10 秒左右再查比较符合真实情况。第三件做数据比对脚本。源库和目标库之间如果建了 dblink可以用 SQL 快速核对表行数SELECT COUNT(*) FROM SCOTT.ORDERSSRC_DBLINK; SELECT COUNT(*) FROM BIZ.ORDERS;逻辑说明行数一致不代表数据一致但行数不一致一定有问题。要更严格可以对关键表按主键做 checksum 比对比如把主键和核心字段拼接后算 MD5。不过这种全表比对很耗目标库性能我一般只对余额表、订单表这种核心表做其他表在控制台里看延迟秒数就够了。5. 安装配置避坑现象→原因→解决DSGRealSync 安装配置阶段的问题来来回回就那么几类我整理五条最典型、也是最容易被新手误判的踩坑记录每一条都按现象、原因、解决三个环节写清楚。5.1 现象采集端启动即报日志缺口错误采集端启动几分钟后日志里出现log gap或类似归档不连续的报错控制台显示采集 SCN 长期不前进。原因源库归档模式虽然开了但 DBA 做过清理或日志被手工删除导致采集端要读的归档段已经不存在。另一个常见场景是采集端停了一周后重新启动源库日志早就覆盖到更早的位置。解决如果缺口不大先检查归档目录里实际存在的日志文件范围确认是否真的缺段如果缺失太多最快的办法不是硬追而是重新做一次全量初始化让采集端从当前 SCN 开始继续同步。要避免这个问题源库归档保留时间要大于你允许的最大停机时间生产环境至少保留 48 小时以上。5.2 现象Apply 进程启动后马上退出日志出现 ORA-01438装载端启动时报ORA-01438: value larger than specified precision allowed for this column进程自动退出。原因目标表字段精度小于源表。比如源表NUMERIC(18,4)目标建成NUMERIC(10,2)数据一旦超过 8 位整数就写不进去。DSGRealSync 默认遇到这种情况会记录错误事务并退出当前装载线程防止目标库数据错乱。解决先看错误日志里是哪张表哪个字段比对源目标两端表结构把目标表字段精度修改到和源表一致。修改表结构前要清理掉错误事务日志中已经排队的历史失败事务否则启动后再次触发。我建议在初始化链路前就用 SQL 把两端表结构做一次自动比对不要等到跑起来才发现。5.3 现象目标库中文变成问号或乱码数据同步过去后客户端查出来中文全是?或者乱码。原因源库字符集是ZHS16GBK目标库是AL32UTF8而 DSGRealSync 进程的NLS_LANG没设置Java 进程默认取系统 locale导致装载端写入时字符串编码和数据库字符集不匹配。解决在启动 DSGRealSync 进程的用户环境里显式设置字符集export NLS_LANGAMERICAN_AMERICA.AL32UTF8如果源库是 GBK则设为SIMPLIFIED CHINESE_CHINA.ZHS16GBK。有一个原则是NLS_LANG要和目标库字符集保持一致装载端写目标库时按NLS_LANG转码不一致就会乱码。这个变量同样要写进.bash_profile别只挂着临时 export。5.4 现象加载不了 native library提示找不到 libclntsh.so采集端或装载端启动时日志里出现Failed to load native library: libclntsh.so或cannot open shared object file。原因DSGRealSync 的 Java 进程通过 JNI 调用 Oracle OCI 客户端库进程启动时LD_LIBRARY_PATH里没有指向 Instant Client 的安装目录或者机器上装了多个 Oracle 客户端版本加载到了不兼容的那个。解决先确认 Instant Client 安装目录下有libclntsh.so再把它所在的目录加入LD_LIBRARY_PATH并用ldd检查依赖是否完整。这里有个容易忽略的点如果你通过 systemd 或 crontab 启动 DSG 进程这些工具默认不会加载你.bash_profile里的环境变量要在启动脚本里显式export或者在 systemd service 文件里指定EnvironmentLD_LIBRARY_PATH/usr/local/instantclient_19_18。5.5 现象管理控制台能打开但各节点状态全部显示离线浏览器访问控制台正常页面能打开但采集端、装载端节点状态全是灰的。原因控制台是一个独立 Web 服务它和各节点之间的心跳走独立的端口。最常见的是防火墙只放通了 8443 的 Web 端口7881 心跳端口被拦截或者是各节点的 agent 代理进程没有启动。解决先用ss -lntp看服务器上 7881 端口有没有进程监听没监听就先启动 agent 进程有监听就 telnet 一下端口确认连通性。控制台和各节点时间差太大也会导致心跳判断失效最好把所有服务器的时间同步配置好这问题在虚拟化环境里尤其常见。6. 上线前写一个自检脚本延迟监控与自动拉起链路调完并稳定跑了两天之后我习惯写一个自检脚本把它丢进 crontab 每五分钟跑一次这样即使半夜链路断了也不至于等到第二天业务反馈数据不对才发现。核心检查两个维度进程是否存活复制延迟是否超过阈值。#!/bin/bash # DSGRealSync 链路自检脚本适用于采集端、装载端同机部署场景 LOG/data/dsg/log/selfcheck.log TARGET_DBdsg_target/Passw0rd//192.168.10.30:1521/ORCLTGT LAG_LIMIT30 check_proc() { if ! pgrep -f dsg_capture.*real_sync_capture.ini /dev/null; then echo $(date %F %T) capture down, restarting $LOG /data/dsg/bin/dsg_capture start --conf /data/dsg/conf/real_sync_capture.ini fi if ! pgrep -f dsg_apply.*real_sync_apply.ini /dev/null; then echo $(date %F %T) apply down, restarting $LOG /data/dsg/bin/dsg_apply start --conf /data/dsg/conf/real_sync_apply.ini fi } check_lag() { LAG$(sqlplus -s $TARGET_DB SQL set pagesize 0 feedback off select round(sysdate - max(update_time),4) * 86400 from biz.orders; exit SQL ) if [ -n $LAG ] [ $LAG -gt $LAG_LIMIT ]; then echo $(date %F %T) lag ${LAG}s, please check apply log $LOG tail -50 /data/dsg/log/apply.log $LOG fi } check_proc check_lag逻辑说明check_proc用pgrep -f匹配完整命令行避免同名进程误判。如果进程不存在直接启动对应组件。check_lag用 sqlplus 查目标库中一张已知会持续更新的业务表取最大更新时间到当前时间的差值作为延迟秒数这比看控制台状态更准确因为它反映的是数据真的写到了哪一步。参数说明LAG_LIMIT30是延迟阈值业务敏感的可以改成 10如果目标库是分析型数据库批量写入本来就有一定延迟可以放宽到 60。biz.orders是你配置同步的其中一张表建议选更新时间比较频繁的那张如果选一张一周才更新一次的表延迟检查等于失效。脚本里没有做数据一致性校验那是另一个重量级话题进程和延迟检查是性价比最高的两道防线。我在上线前还会做一件有点强迫症的事把采集端、装载端的内存配置和文件句柄限制提前核一遍尤其是ulimit -n同步表特别多时文件句柄不够会随机出现写入失败这类问题往往和 DSGRealSync 配置无关但表现很像同步软件 bug。把自检脚本布置好之后链路才算真正达到一个能放心交给业务的状态。希望这篇安装配置笔记能帮你少走点弯路真遇到解决不了的问题第一时间把采集端和装载端的日志同时拉出来对比十有八九能找到答案。本文还有配套的精品资源点击获取