简介迪思杰Realsync管理维护手册是数据库同步复制领域的一份技术文档适合DBA、系统运维及数据架构师参考旨在阐明日志级复制原理与运维要点。手册从日志抓取、日志分析、交易合成到数据传输与装载完整还原了源库与目标库之间实时一致的核心链路并梳理了首次全同步、复制关系维护以及DML与DDL操作的支持范围便于管理员判断哪些变更可自动复制、哪些异常需人工介入。包体为1个DOC文件约350KB49页内容按章节编排目录覆盖各复制端口一览、软件部署结构、发起全同步并启动复制以及源端/目标端安装目录和重点文件说明整体结构清晰既适合实施前规划也适合故障排查时对照。目前已有121人浏览学习对于正在使用或评估迪思杰同步工具的技术人员该文档能显著降低上手与维护成本。1. 为什么数据同步工具还需要一份“维护手册”很多团队第一次接触 DSG Realsync 时把它当成又一个“装上就能跑”的同步工具等真正上了生产才发现它处理的是数据库底层的 redo/archive 日志链路上一旦出现延迟或中断影响的不是一个接口而是下游一批报表、风控批处理和容灾切换。这个时候再翻官方文档往往被几百页的安装说明和函数清单淹没找不到“我现在该先看哪条命令、哪个参数能保命”的关键入口。这份管理维护手册的价值不是告诉你 Realmatch 和 Realsync 的关系也不是罗列菜单项而是把日常维护里最常踩的坑、最该记住的检查点、以及不重启任务就能临时止血的手段讲清楚。它适合的读者是数据库管理员、系统集成工程师和负责容灾演练的运维人员——尤其适合那些已经把同步任务跑起来、但只敢看状态灯、不敢动配置的人。本文将按“原理前置 → 配置实战 → 运维排错 → 进阶技巧”的顺序展开保证你读完后能自己动手定位问题。2. 从日志解析到目标入库Realsync 同步原理与部署前置2.1 它不是物化视图也不是双写日志解析的同步模型DSG Realsync 的底层逻辑是解析源数据库的 redo log 或 archive log从中还原出事务级的 INSERT、UPDATE、DELETE 操作再按事务提交顺序发往目标端执行。这个模型和基于查询的同步有本质区别源库不需要额外开触发器也不需要为每条变更额外写业务代码对源库性能影响极小。但它也意味着Realsync 必须能读懂数据库的内部日志格式所以版本匹配非常严格——Oracle 11g 的日志格式和 19c 不同补丁版本变了也可能导致解析失败。目标端应用变更时Realsync 通常采用多线程并发回放但必须保证同一主键的事务顺序不乱。所以它在内部有“事务队列”和“依赖锁”机制不同表可以并行回放同一张表上的同主键操作会排队。理解这一点你才能解释为什么表数量多、主键多的任务延迟可能更高也才能理解后面调参时为什么不能盲目加大并发线程数。2.2 部署前源库检查5 条命令提前确认工作量很多维护问题在部署前就埋下了。源库如果没有开启归档日志Realsync 只能解析当前在线日志一旦日志切换没来得及同步的数据就永久丢失。至少执行以下检查# 在源库以 DBA 身份执行 sqlplus / as sysdba SQL archive log list; -- 确认 Database log mode 为 Archive Mode若不是则需开启归档并重启实例 SQL SELECT supplemental_log_data_min, force_logging FROM v$database; -- 期望输出 MINYESFORCE_LOGGINGYES否则补数逻辑可能漏读 SQL SELECT NAME, VALUE FROM v$parameter WHERE NAME IN (db_recovery_file_dest_size, archive_lag_target); -- 确认归档空间足够建议至少保留 72 小时的归档量补充日志supplemental log是 Realsync 还原 UPDATE 前映像的关键。如果没有开启最小补充日志UPDATE 语句在日志里只记录被修改的列Realsync 无法定位到具体行只能回退为全表更新或报错。FORCE_LOGGING则是防止某些表被 NOLOGGING 模式跳过日志生成导致变更不完整。这两项不满足后面同步越跑越“看起来正常”实际目标端数据是错的。2.3 安装目录与核心进程先认识进程再谈维护Realsync 安装后的目录结构通常包含bin可执行程序、conf同步任务配置、log运行日志、data队列缓存文件。安装完成后通过进程名即可判断核心组件是否拉起ps -ef | grep -E rep_task|sync_engine|rs_manager | grep -v grep不同版本进程名可能有差异但重点关注两类一个是管理/守护进程负责接收管理端的启停指令一个是任务工作进程每个同步任务在系统里对应一个独立进程进程崩溃往往意味着该任务中断而不会影响其他任务。在维护现场建议用ls -lt log/先看最近修改的日志文件再按文件名过滤任务 ID而不是盲目打开几十个文件逐个找错误。提示不要把 Realsync 安装目录放在源数据库的数据盘上。它自身会写队列缓存耗磁盘 IO放一起容易互相拖累排查问题时也难分清楚是谁在占用 IO。3. 配置同步任务表映射、主键规则与三个性能参数3.1 用配置界面或命令行建一个最小同步任务部署完成后配置同步任务的常见路径是通过管理端图形界面注册源库、目标库再选择需要同步的表。如果是命令行环境通常提供类似rs_client的命令行交互工具。无论哪种方式核心配置项都落在目标端对应的 task 配置文件中。一个最小化的任务配置文件片段如下示例格式以实际版本为准[task] task_name orcl_to_mysql_01 source_type ORACLE target_type MYSQL source_tns (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST192.168.1.10)(PORT1521))(CONNECT_DATA(SERVICE_NAMEORCLPDB1))) target_conn jdbc:mysql://192.168.1.20:3306/replica?useSSLfalserewriteBatchedStatementstrue [table_map] schema1.T_ORDER - replica.t_order schema1.T_USER - replica.t_user [parallel] commit_threads 4 io_threads 2 batch_size 500配置里最关键的是table_map这一段。它决定源表与目标表的对应关系不仅支持同构同步也支持异构数据库之间的字段类型转换。commit_threads控制目标端提交线程数io_threads控制日志读取线程数batch_size则是攒多少条变更再打包发送。初次配置不建议一上来就追求高并发先把任务跑通、延迟降下来再逐步调大。3.2 决定同步性能的三个参数按这个顺序去调很多运维人员一看到延迟就盲目加commit_threads结果目标库事务冲突反而变多。正确的调优顺序是先保证源端读取不滞后再看网络传输最后调目标端回放。io_threads负责读取归档日志并解析。如果源库日志量极大可以从 1 调到 2 或 3但要观察log/reader_*.log中是否出现“cannot keep up”的告警。这个参数调太大不会线性提速反而会让日志解析顺序碎片化。batch_size单位是条数代表一次打包多少条变更发送到目标端。网络延迟高的时候增大batch_size能减少往返次数但每条记录包含完整的前后映像批量过大容易触发目标端事务超时。commit_threads目标端回放线程数。它受目标数据库的锁竞争影响最大尤其是热点表只有 1~2 张时线程多了反而排队。一个稳妥经验是先设 4观察目标库 AAS平均活动会话数若 AAS 低于 CPU 核数且延迟未下降再往上加。提示修改commit_threads和io_threads后一般不需要重启整个 Realsync 服务只要重启对应的同步任务即可。具体命令是登入管理端后先 stop 任务修改配置再 start 任务避免影响其他任务。3.3 冲突解决机制先把冲突归档再人工干预同步过程中主键冲突是最常见的错误类型。场景通常是源端执行了先 DELETE 再 INSERT但 Realsync 按日志顺序发送时INSERT 先到了目标端而 DELETE 还没执行如果目标表没有提前删除旧数据就会出现主键重复。Realsync 的默认行为不是跳过冲突而是把冲突记录写入异常归档表或错误日志文件任务继续跑后面的数据。这样设计的好处是避免单个坏事务卡死整个链路坏处是如果没人处理异常表目标库的差异会越积越大。正确的维护手段是周期检查异常表-- 在目标端查询异常记录以 MySQL 为例 SELECT task_id, table_name, pk_value, op_type, error_msg, create_time FROM dsg_exception_log WHERE create_time NOW() - INTERVAL 1 DAY ORDER BY create_time DESC;查出来后需要根据op_type和pk_value手动补做相同操作。常见手工修法如果是重复 INSERT先删掉目标端残留的旧记录再让任务重新发送如果是 UPDATE 找不到行说明源端 DELETE 还没同步过来可以忽略等待也可以手动补一条 DELETE。这里最忌讳的是直接“清空目标表全量重灌”除非你能确认延迟窗口内没有新的变更进入否则会造成更大的数据空洞。4. 日常维护与排错不重启任务的实时监控与定位手段4.1 怎么看同步是否“真正”正常延迟、队列、心跳日常巡检不能只看任务状态是“运行中”还要关注延迟lag和队列积压。Realsync 管理端通常提供status或monitor命令显示每个任务的当前延迟字节数和时间差。命令行下常见的是登录管理端执行rs_admin show task detail task_nameorcl_to_mysql_01输出中稳定出现这几个指标Current SCN当前已解析到的日志位点、Source Latest SCN源库最新位点、Target Applied SCN目标端已应用位点、Queued Entries待发送队列中的变更条目数。正常情况下Queued Entries应该接近 0 或在短时间内波动后回落。如果它持续增长说明目标端回放速度跟不上源端变更速度此时才需要调commit_threads或检查目标库瓶颈。还有一个容易忽略的点是心跳表。Realsync 通常支持在源端写入心跳记录用来在“无业务变更时段”验证链路是否仍保活。如果业务低峰期目标端数据完全不动延迟又看不出来可以查心跳表的最新时间戳是否持续推进-- 目标端心跳表检查 SELECT MAX(heartbeat_time) FROM dsg_heartbeat WHERE task_id orcl_to_mysql_01;如果心跳时间停在几分钟前说明链路可能已经断开但任务状态还没来得及更新。4.2 归档日志堆积先判断是同步慢还是没人读源库归档目录爆满是 DBA 最先感知到的同步故障。常见反应是“Realsync 是不是挂了”实际原因可能是同步任务正常但归档日志保留策略太长也可能确实是 Realsync 停止了读取。判断方法很简单看归档目录里文件的最新修改时间和进程的日志读取位点# 查看最近归档日志生成时间 ls -lt $ORACLE_BASE/fast_recovery_area/ORCL/archivelog | head -5 # 查看当前同步任务读取位置进入管理端 rs_admin show task status task_nameorcl_to_mysql_01如果归档日志最新文件的生成时间只比当前时间晚 1~2 分钟而任务读取位置落后很多说明 Realsync 处理不过来。此时应该调大io_threads而不是先去扩归档空间。如果归档文件已经不再增长但还有大量旧归档没被清理通常是同步任务已经停掉需要查log/error_*.log里最近的报错。还有一个容易踩的坑有些维护人员会手动删除旧归档来释放空间这在 Oracle 开启db_recovery_file_dest的情况下会让 Realsync 找不到日志文件任务直接中止。安全做法是确认任务读取位点已经越过该归档文件后用RMAN或 Oracle 自身的清理策略删除而不是rm。4.3 目标端表数据不一致的三个定位步骤数据不一致通常不是一次性出现的而是某个时间点开始持续累积。直接比对所有表不现实可靠的定位路径是先找时间点再找表最后找具体记录。-- 步骤1对比源端和目标端记录数找出差异最大的表 -- 源端 SELECT COUNT(*) FROM schema1.T_ORDER; -- 目标端 SELECT COUNT(*) FROM replica.t_order; -- 步骤2如果数量差异明显提取源端主键集合与目标端比对 -- 以 MySQL 端为例找出目标端多余的主键 SELECT pk_value FROM replica.t_order WHERE pk_value NOT IN ( SELECT pk_value FROM dsg_exception_log WHERE table_namet_order );操作时注意大表上的COUNT(*)会带来压力建议放在业务低峰期。定位到差异表后还需要结合异常日志确认是该表一直有冲突没解决还是从某个时间点开始同步就丢数据。回看该表的同步日志例如log/t_ord_*.log搜索error或warn关键字就能看到具体是什么操作失败了。这个过程中不要尝试去修改 Realsync 内部队列文件那是最后手段一般先用异常表的记录就能解释 80% 的差异来源。5. 用“基线 增量重建”快速恢复单表数据恢复单表数据是维护手册之外的隐藏技能。如果发现某张表差异巨大、异常日志堆积了几万条逐条手工修不现实。常见做法是重建这张表的同步基线暂停任务、抽取源端当前数据全量导入目标端、重置同步位点到导入开始时的 SCN再恢复增量。Realsync 通常提供导数工具或支持对接数据抽取服务。操作时要保证导出期间源表没有大事务否则导入的数据和增量位点对不上恢复后仍然不一致。以手工操作为例# 1. 停任务避免增量继续追 rs_admin stop task task_nameorcl_to_mysql_01 # 2. 导出源表数据示例为逻辑导出 expdp schema1/t_ORDER directoryDMP_DIR dumpfilet_order_full.dmp logfilet_order_exp.log # 3. 导入目标端前先清空目标表确认已停止该表同步 mysql -u replica -p -e TRUNCATE TABLE replica.t_order; # 4. 导入并重建索引 impdp directoryDMP_DIR dumpfilet_order_full.dmp table_exists_actionreplace此方案的关键是记录导出开始的时间点。最好在导出前先记录源库当前 SCN然后在导出完成后把任务位点重置到该 SCN。Realsync 的重置命令通常位于任务管理的“位点管理”菜单填写 SCN 后任务会从该位点重新开始读取日志而不是从头解析归档。如果重置位点早于导出开始时间不会有问题只是重复应用已经导过的数据如果晚于就会漏掉导出期间的新增变更造成永久缺失。恢复之后不要急着观察延迟先做一次小范围校验对比源端和目标端最近 5 分钟内的新增主键确认两边一致再放开监控告警阈值。整个恢复过程最怕的是导出半途失败而任务已经启动所以在停任务阶段务必先确认源端没有正在执行 DDL否则那张表的元数据变化会导致同步中途报错。本文还有配套的精品资源点击获取