Realsync数据库同步工具运维指南：从Redo Log抓取到XF1装载与调优

简介面向数据库管理员、数据运维工程师及信息化团队DSG Realsync管理维护手册系统讲解基于日志级的实时同步复制技术。内容涵盖日志抓取、分析、交易合成、交易传输与数据装载的完整原理逐一说明首次全同步、复制关系维护、DML/DDL操作复制支持并给出常见不支持操作的处理建议。手册同时附有各复制端口功能一览表、软件部署结构说明、发起全同步并启动复制流程以及源端/目标端目录和重点文件配置讲解方便管理员日常巡检、性能调优和故障排查。资源共包含1个doc文档大小350KB结构清晰、可直接按章节查阅覆盖从部署到排错的完整运维链路。目前已有121人学习下载适合正在使用或评估迪思杰Realsync同步工具的技术人员快速掌握同步复制机制的落地要点。1. Realsync 数据库同步复制工具为什么说维护重点不在同步算法Realsync 是迪思杰DSG的数据库同步复制工具核心思路是在源端读取 Oracle Redo Log分析出完整交易后以 XF1 格式发送到目标端装载。和直接传归档日志、目标端做 recover 的方案相比它传的是分析后的交易数据量小目标端数据库可以保持打开状态。真正需要运维人员上心的不是同步算法本身而是端口分配、日志分析间隔、DDL 过滤规则和队列积压这几个维护点。这份管理维护手册适合两类人看一类是刚接手 Oracle 到 Oracle 实时同步的 DBA需要快速理解链路里每个进程在干什么另一类是已经在跑 Realsync、但遇到增量延迟或目标端数据不一致时不知道怎么定位的运维工程师。整套内容的组织顺序是同步原理、链路拆分、部署目录、日常命令最后是两个容易漏掉的细节。2. 复制链路拆分日志抓取、交易合成与 XF1 装载2.1 日志抓取SCN 轮询与 Online Log CacheRealsync 在源端的 Agent 并不会持续盯着日志文件而是定期查询 Oracle 系统视图中的当前 SCN 号判断有没有新交易产生。SCN 变了才去读取对应 Redo Log 组和日志位置抓取的日志先落到 Online Log Cache再交给下一步分析。这样设计的直接好处是避免频繁读取日志文件带来的 I/O 开销对生产库影响比较小。手册给出的设计目标是每秒能分析约 10MB 日志量运维调优时可以以这个数值为基准推算同步延迟。维护时如果要确认日志抓取是否正常可以对照查看数据库日志状态SELECT CURRENT_SCN, STATUS FROM V$DATABASE; SELECT GROUP#, SEQUENCE#, STATUS, BYTES / 1024 AS SIZE_MB FROM V$LOG ORDER BY GROUP#;第一句检查当前 SCN 和数据库状态第二句查看日志组序号、状态和大小。V$LOG 中如果长时间只有一两个 ACTIVE 且没有归档行为说明日志切换或归档可能出了问题Realsync 日志抓取会跟着延迟。日常巡检时把这两条 SQL 的输出和源端 Agent 日志里的 SCN 做对比能快速判断是数据库侧没产生日志还是 Agent 没抓到日志。2.2 交易合成为什么以 Transaction 为单位Redo Log 中一个交易的多条 SQL 并不是连续存放的多个交易相互穿插而且日志里同时包含已提交、未提交、回滚三类内容。Realsync 的交易合成模块会先按交易序号把 SQL 归组然后只把已提交的交易送去传输。未提交的交易暂存在本地缓存等后续日志中看到该交易提交后再发送回滚的交易直接丢弃不进入传输环节。这个设计对目标端非常重要。如果按单条 SQL 为单位传输目标端会反复处于中间状态一旦传输中断很难判断哪些数据是有效的。以交易为单位传输后目标端收到的每个包都是一个完整提交的事务装载失败时可以直接定位到整个交易并做重放处理。日志中的交易状态Realsync 处理方式目标端表现已提交 Commit合成后立即传输按顺序装载最终可见未提交保存在缓存提交后再传输延迟装载不会提前可见回滚 Rollback直接丢弃不产生任何装载动作生产环境中常见的一个误区是看到源端日志里有大量未提交事务就以为同步滞后。其实只要这些交易没有提交Realsync 不传输是正常行为。真正该关注的是已提交交易从出现在日志到送达目标端的时间差。2.3 XF1 格式与 ROWID Mapping 装载XF1 是 DSG 的专有数据格式用来表达 SQL 指令优势在于可以直接转换成 Oracle 内部数据表达格式不需要经过完整的 SQL 层解析。Oracle 提供了 User、SQL、Transformation、I/O 四层接口普通 JDBC 或 SQL*Plus 装载走 User 层而 XF1 装载尽量下沉到 I/O 层省掉 parse、plan 带来的开销。另一个关键点是 ROWID Mapping。Update 和 Delete 在没有主键的情况下定位记录很慢Realsync 在首次全同步或首批 insert 时建立源端 rowid 到目标端 rowid 的映射表装载时直接按目标端 rowid 定位写入位置避免在大量并发 DML 中反复扫描索引。每条记录的映射关系是在该记录执行 insert、sql loader 或首次批量同步时建立起来的。对比项标准 SQL 装载XF1 ROWID Mapping数据入口User 层I/O 层记录定位Where 子句走索引目标端 rowid 直接定位高并发 Update/Delete解析开销大索引扫描多开销低受映射表维护影响适用场景通用性要求高、数据量小大数据量、实时同步这也是实际项目中 Realsync 目标端负载通常远低于源端的原因。维护人员要留意的不是装载 SQL 优化而是映射表是否完整。全同步后如果源端出现大量 nologging 操作映射关系可能没有建立起来后续更新会定位失败这类问题往往只能重新全同步恢复。3. 部署目录与端口配置源端和目标端的对应关系3.1 源端安装目录里该盯哪些文件Realsync 源端目录结构并不复杂常见安装路径是 /oracle/realsync各子目录职责如下$REALSYNC_HOME/ ├── config/ # 复制对象、DDL过滤、日志分析间隔等配置 ├── scripts/ # 全同步与启停脚本如 full_sync_ds.sh、start_dsg.sh ├── bin/ # Agent 可执行程序涉及日志抓取与发送 ├── log/ # 运行日志排障时优先查看 └── rmp/ # XF1 队列缓存判断是否积压看这里config 目录是维护重点复制关系、过滤规则都在这里修改。scripts 目录里维护脚本的执行用户和权限要保持一致常见做法是统一用 oracle 系统用户执行。log 目录日志文件增长很快磁盘写满会直接拖住 Agent。rmp 目录是交易数据暂存区域日常说的 XF1 积压就体现在这里。下文命令里$REALSYNC_HOME指 RealSync 的安装根目录实际环境中通常是 /oracle/realsync 或 /dsg/realsync。3.2 目标端安装目录与源端的差别目标端目录比源端少一个 config 目录接收和装载程序在 bin 下scripts 里主要是 full_sync_dt.sh、start_dsg_dt.sh 这类配套脚本。目标端 log 中重点是装载日志rmp 目录同样用于队列缓存。两端 rmp 目录要区分看待源端 rmp 积压说明日志分析或传输慢目标端 rmp 积压说明装载能力不足或目标库存在锁等待。目录源端用途目标端用途积压时含义config复制规则、过滤配置无源端配置不当可能引发复制异常scriptsfull_sync_ds.sh / start_dsg.shfull_sync_dt.sh / start_dsg_dt.sh脚本版本不一致会导致全同步流程错乱log抓取、分析、发送日志接收、装载日志错误集中在装载阶段rmpXF1 待发送队列XF1 待装载队列源端积压查传输目标端积压查装载3.3 端口分配与防火墙放通Realsync 两端进程通过固定端口通信。源端 dbpsd 监听管理控制连接目标端 vagentd 接收传输进程发来的交易包。典型端口对应关系如下位置进程端口连接方向源端dbpsd60000管理端连接源端目标端vagentd60001源端 sender 连接目标端本地复制和远程复制通常会各分配一套端口项目里见过 60000/60001 与 50000/50001 并存的情况。配置变更后检查监听是否生效netstat -tlnp | grep -E 60000|60001输出里能看到 dbpsd 或 vagentd 进程监听对应端口即正常。防火墙策略要单独放通这两个端口不要简单关闭系统防火墙了事。另外端口不要和生产数据库监听端口混在一起避免网络管理员误判也不要让其他进程占用这些端口。4. 日常维护命令进程检查、日志监控、队列积压与重新全同步4.1 进程检查与正常启停Realsync 的日常检查通常从进程和队列两个维度入手。源端进程与目标端进程分别负责不同阶段检查命令ps -ef | grep -E dbpsd|vagentd|sender|loader | grep -v grep输出里应能看到源端 dbpsd、sender 以及目标端 vagentd、loader 对应进程。grep sender 时要注意区分同名操作系统进程建议先执行ps -ef | grep realsync看完整路径再做精确匹配。若某一边进程反复重启或不稳定先看 log 目录下对应日志不要直接 kill 后重启否则可能丢掉未完成队列。常规启动和停止顺序有讲究。停止时先停源端再停目标端避免目标端还在收数据源端已经不在启动时反过来先启源端抓取日志再启目标端等待接收。常见做法是通过 scripts 下脚本执行例如启动源端执行 start_dsg.sh启动目标端执行 start_dsg_dt.sh# 启动源端 Agent /oracle/realsync/scripts/start_dsg.sh # 启动目标端 Agent /oracle/realsync/scripts/start_dsg_dt.sh提示执行脚本前确认当前用户是 oracle且脚本有执行权限。用 root 执行会有目录权限问题进程起不来还容易留下半启动状态。4.2 日志监控分析日志和装载日志分开看源端日志重点看日志分析是否跟上生产写入速度目标端日志重点看装载失败。查看最新日志文件cd $REALSYNC_HOME/log ls -lt *.log | head tail -f $(ls -t *.log | head -1)第一行列出按修改时间倒序的日志文件第二行跟踪最新文件的末尾。看到持续有内容输出说明进程在工作长时间没有新输出要检查进程是否假死。排查错误时用关键字过滤grep -iE error|ora-|fail $REALSYNC_HOME/log/*.log | tail -50ORA- 后面的编号就是 Oracle 错误码比如 ORA-01403 表示记录未找到通常和 ROWID Mapping 失效有关ORA-00001 表示主键冲突常见于目标表已有数据时重复装载。目标端装载日志里出现约束类错误时先确认是不是做过重复初始化不要急着清队列。4.3 队列积压xf1 文件数量怎么看交易数据以 XF1 格式暂存在 rmp 目录中等待发送或装载。检查积压最直接的方法是统计 rmp 目录文件数量与增长趋势ls $REALSYNC_HOME/rmp/*.xf1 2/dev/null | wc -l find $REALSYNC_HOME/rmp -name *.xf1 -mmin 10 | wc -l第一行统计当前未处理文件总数第二行统计超过 10 分钟仍未处理的文件数。如果总数持续增长说明产生速度大于消费速度如果存在大量超过 10 分钟的文件基本可以断定某一段链路卡住了。定位思路是源端 rmp 积压看 sender 进程是否正常、网络是否通畅目标端 rmp 积压则查看目标库的锁等待、装载进程是否存在死循环。4.4 重新全同步四步脚本流程当目标端数据不一致、发生大量 nologging 操作导致增量丢失或者复制关系大范围调整时需要重新发起全同步。Realsync 手册中的标准流程是四步# 1. 停止并清空源端 realsync 程序 /oracle/realsync/scripts/full_sync_ds.sh # 2. 停止并清空目标端 realsync 程序 /oracle/realsync/scripts/full_sync_dt.sh # 3. 重新启动源端 realsync 程序 /oracle/realsync/scripts/start_dsg.sh # 4. 重新启动目标端 realsync 程序 /oracle/realsync/scripts/start_dsg_dt.sh顺序不能颠倒先清源端再清目标端避免源端还在推数据而目标端队列被清空导致数据缺口。启动是源端在前、目标端在后全同步开始后源端先把当前数据全量装载到目标端这个阶段目标端 rmp 和装载日志都会有明显活动。脚本作用执行顺序full_sync_ds.sh停止并清空源端1full_sync_dt.sh停止并清空目标端2start_dsg.sh启动源端3start_dsg_dt.sh启动目标端4确认全同步结束并进入实时同步阶段可以看两个信号目标端日志中不再出现全量装载条目源端 rmp 目录文件数量下降并保持稳定且源端日志中的 SCN 持续推进。若全同步后目标端仍有大量错误检查是否清空不彻底需要重新执行两个清空脚本再走一遍流程。5. 两个容易被忽略的运维技巧DDL 过滤与分析间隔调整5.1 过滤破坏性 DDL三级别配置同步环境里最怕的不是 DML 量大而是误操作把 drop table、truncate table 也复制到目标端。Realsync 支持 database、user、table 三个级别的 DDL 过滤分别控制不同范围。database 级可过滤 role、user、dblink、profile 这类对象操作user 级可配置某个 schema 下所有 drop table 等破坏性操作不同步table 级则针对指定的重要表避免核心表被 truncate 影响。过滤级别典型配置对象实际效果databaserole、user、dblink、profile数据库级对象操作整体放行或拦截userschema 下的 DDL指定用户下 drop/truncate 不复制table指定表核心表的 drop/truncate 被过滤配置位置在源端 config 目录的过滤列表中维护时修改后需要重启源端 Agent 生效。验证过滤是否生效最安全的做法是在测试库上执行一条被过滤的 DDL比如对一张测试表执行 truncate然后检查目标端对应表是否还在。目标端表未受影响说明规则已加载。注意过滤规则只影响后续 DDL已经到达目标端的交易不会被追回。5.2 调整日志分析间隔先观察再修改日志分析间隔决定了 Agent 多久检查一次 SCN。间隔太短源端 CPU 消耗增大间隔太长同步延迟变高。这项参数没有固定最优值与生产库日志产生量、Agent 所在主机性能都有关系。我一般会这样调先用默认间隔运行一两天记录源端 Agent 的 CPU 占用率和 rmp 目录的积压情况。如果 CPU 占用不高但同步延迟明显就把间隔调小一档如果 CPU 已经偏高且 rmp 文件还在增加问题通常出在分析性能或传输链路上继续调小间隔只会让情况更糟。修改间隔同样在 config 目录中完成调整后重启源端进程观察日志中 SCN 推进与日志分析耗时的变化。验证方法可以直接对比源端 Redo Log 产生时间和目标端装载完成时间之间的差值。注意不要为了追求低延迟把间隔调到极小Realsync 作为日志级复制工具保留一个合理的批处理窗口反而能提升整体吞吐。本文还有配套的精品资源点击获取