企业官网建设流程全解析

简介：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，把所有同步组件和数据文件都归到这个账号下。

参数说明：上面三个端口是我在项目里的常见规划，不同版本安装包默认值可能不一样，具体以你拿到的安装说明为准。规划端口时要注意两点：一是不要和已有业务的端口冲突，二是防火墙里要把这三类端口都放通，很多控制台显示节点离线，原因不是服务挂了，而是 7881 心跳端口被防火墙挡了。

目录权限方面，我建议把队列、日志和安装目录分开。比如用/data/dsg/app放程序，/data/dsg/queue放待投递数据，/data/dsg/log放运行日志，然后chown -R syncuser:syncgrp /data/dsg。队列目录尽量不要和系统根分区放一起，同步高峰时队列文件增长很快，根分区写满的后果是整个操作系统进入只读状态，这是我在生产环境见过最严重的翻车现场之一。

3. 安装DSGRealSync的完整步骤：从解压到链路启动

环境就绪后，正式安装分四步：解压划分目录、配置采集端、配置装载端、启动控制台并拉起链路。下面按顺序走，每一节都给了可以直接抄的配置片段。

3.1 解压安装包并划分目录结构：组件各自归位

安装包解压后不要一股脑全扔到/opt，DSGRealSync 按职责大概分三块：采集端负责读日志，装载端负责写目标库，控制台负责监控管理。我习惯在/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_type=ORACLE db_user=dsg_user db_password=Encrypted@123 db_host=192.168.10.20 db_port=1521 db_service=ORCLPDB1 archive_mode=ARCHIVELOG mining_log=REDO_ARCHIVE [QUEUE] queue_dir=/data/dsg/queue queue_size=4096 [SYNC] timeout_sec=60 retry_times=5

逻辑说明：db_user是源库独立建的同步账号，不要直接拿SYS或SYSTEM用，生产环境权限控制严格，独立账号便于审计和回收权限。archive_mode=ARCHIVELOG表示源库必须运行在归档模式下，如果源库是非归档模式，采集端读不到历史日志，链路根本起不来。mining_log=REDO_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_type=ORACLE db_user=dsg_target db_password=Encrypted@456 db_host=192.168.10.30 db_port=1521 db_service=ORCLTGT sync_mode=CE mapping_file=/data/dsg/conf/mapping_rule.xml [TXN] commit_batch=500 write_threads=4 error_log=/data/dsg/log/error_txn.log

逻辑说明：sync_mode=CE是提交等价模式，意思是目标端事务的提交顺序尽量与源端保持一致，保证数据最终一致性。如果业务允许最终一致，可以考虑sync_mode=ASYNC提高吞吐，但这会导致目标端事务顺序和源端不完全一致，配置前一定要和业务方确认。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_1='location=/oracle/arch' scope=both; alter system set db_recovery_file_dest_size=512G scope=both; 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 source="SCOTT.ORDERS" target="BIZ.ORDERS" /> <table source="SCOTT.CUSTOMER" target="BIZ.CUSTOMER" condition="REGION='CN'" /> <ignore-table source="SCOTT.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.ORDERS@SRC_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_LANG=AMERICAN_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 文件里指定Environment=LD_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_DB="dsg_target/Passw0rd@//192.168.10.30:1521/ORCLTGT" LAG_LIMIT=30 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_LIMIT=30是延迟阈值，业务敏感的可以改成 10，如果目标库是分析型数据库，批量写入本来就有一定延迟，可以放宽到 60。biz.orders是你配置同步的其中一张表，建议选更新时间比较频繁的那张，如果选一张一周才更新一次的表，延迟检查等于失效。

脚本里没有做数据一致性校验，那是另一个重量级话题，进程和延迟检查是性价比最高的两道防线。我在上线前还会做一件有点强迫症的事：把采集端、装载端的内存配置和文件句柄限制提前核一遍，尤其是ulimit -n，同步表特别多时文件句柄不够会随机出现写入失败，这类问题往往和 DSGRealSync 配置无关，但表现很像同步软件 bug。把自检脚本布置好之后，链路才算真正达到一个能放心交给业务的状态。希望这篇安装配置笔记能帮你少走点弯路，真遇到解决不了的问题，第一时间把采集端和装载端的日志同时拉出来对比，十有八九能找到答案。

本文还有配套的精品资源，点击获取