简介DSG Realsync管理维护手册是一份面向数据库管理员和运维人员的实操型技术文档聚焦迪思杰Realsync在不同数据库之间实现实时数据同步的部署、配置与维护尤其适合初次接触或正在评估该复制工具的团队。资源为单份DOC文档共49页压缩包约350KB轻量易携带可作为同步复制工具的手边速查手册。手册完整涵盖REALSYNC工作原理日志抓取、日志分析、交易合成、交易传输、数据装载、复制关系维护与首次全同步流程、DML/DDL操作复制支持情况及常见不支持操作的处理建议、各复制端口一览表并详细说明软件部署结构与源端/目标端安装目录中config、scripts、bin、log、rmp等重点文件的作用帮助管理员从日志级复制原理逐层理解系统架构与实际配置。内容按复制流程、支持能力、端口配置、部署结构逐层展开便于按需查阅。已有121人学习对需要维护跨库数据一致性的团队而言这份手册能显著降低学习门槛提升数据库同步的排障效率。1. 理解 DSG Realsync 在实时数据同步链路中的角色DSG Realsync 是一款以数据库日志解析为核心的实时同步软件主要解决同构或异构数据库之间的数据实时复制问题。很多 DBA 第一次碰到它是在做数据分发、读写分离或容灾切换的时候它不依赖业务系统改造也不要求在应用里写双写逻辑而是直接从源库日志里捕获事务再按提交顺序投递到目标库。这一点让它在运维侧的定位和 ETL 工具明显不同ETL 关心“一批数据对不对”Realsync 这类工具更关心“这条事务到底有没有在目标端生效”。因此实际难点往往不在安装而在配置阶段的位点理解、运行阶段的状态判断、故障阶段的断点恢复。下面按部署检查、任务配置、运行管理、排障恢复和巡检优化来展开一套可复用的维护打法。2. Realsync 部署前置检查与配置参数准备2.1 理解 Realsync 的进程模型采集、传输、回放DSG Realsync 做同步时不会反复对源库执行查询来“找出变化”而是从数据库日志里读取已提交事务。以常见流程为例一条完整同步链路至少包含三个环节源端捕获进程读取在线日志或归档日志把事务解析为内部记录并写入本地队列文件传输进程负责把队列内容分发到目标端目标端的应用进程再按事务先后顺序写入目标数据库。三者之间通过记录位点的 checkpoint 文件保持衔接这也是 Realsync 能实现断点续传的基础。部署前要对这三个环节分别预留资源。捕获进程所在主机重点看磁盘空间和 IO 能力因为队列文件会落到本地磁盘传输环节受网络带宽和两端防火墙影响目标端应用进程需要关注数据库的表结构、约束和字符集。很多初次使用的人把精力集中在数据库连接参数上却忽略了队列目录的磁盘水位一旦目标端故障持续数小时队列积压很容易把磁盘写满。2.1.1 一条同步链路的角色与规划要点下表是部署时通常需要确认的内容链路角色承担工作资源规划要点源端捕获进程日志读取、事务解析日志目录空间、CPU、归档模式本地队列与传输进程数据缓存、网络分发队列磁盘水位、带宽、防火墙目标端应用进程事务回放、约束检查目标库 IO、索引、字符集表里三行的顺序同样代表数据流向排障时先判断故障落在这三段里的哪一段再决定下一步去翻哪类日志而不是一上来就怀疑网络或数据库参数。2.2 一份同步任务配置里的三类参数Realsync 的任务配置在不同版本里格式不完全一致但核心字段基本固定常见做法是把源端连接、目标端连接、同步选项分开维护。这里给出一次任务配置时典型的 YAML 风格字段task: name: task_ora2mysql # 控制台和日志中的任务标识 source: db_type: oracle host: 10.10.1.10 port: 1521 service_name: ORCL user: rs_capture password: ENC(省略) log_mode: archive # archive 表示解析归档日志 target: db_type: mysql host: 10.10.1.30 port: 3306 schema: dsg_app user: rs_apply password: ENC(省略) charset: utf8mb4 # 目标端字符集异构时必填 sync: tables: app.orders,ods.* # 按表名或模式匹配 batch_size: 2000 # 每个批次抓取的行数 parallel_workers: 4 # 目标端回放并行度 queue_dir: /data/rs_queue # 本地队列目录 log_level: info # 排障时可临时调成 debugsource 和 target 两段要注意两个坑。第一源端账号不只是能查询数据还需要具备读取日志位点的权限否则任务反复处于等待日志状态。第二异构同步场景下目标端 charset 如果和源端字符集对不上回放时可能并不报错但数据会乱码或长度溢出这类问题往往跑数小时才暴露定位成本很高。sync 段里的 batch_size 是典型的性能拐点。批量抓取行数越大单位时间解析的事务越多但每批事务在目标端提交时的开销也越大遇到大字段多的表反而会因为单批数据过大拖慢回放。parallel_workers 则决定目标端回放的并发线程数后面会专门说这组参数的调整方向。2.3 启动 Realsync 前的最小链路验证配置完成后不要直接启动整个任务先把两端的连通性和账号权限验一遍。我一般会用下面的命令检查网络和端口nc -zv 10.10.1.10 1521 nc -zv 10.10.1.30 3306第一行测试源端 Oracle 的 1521 端口是否能建立 TCP 连接第二行测试目标端 MySQL 的 3306 端口。这一步能避免把网络禁 ping、防火墙丢包等问题误判成同步软件故障。数据库账号的验证则要实际连库执行查询-- 源端 Oracle 查看日志模式 select log_mode, supplemental_log_data_min from v$database; -- 目标端 MySQL 确认库可写、字符集一致 select character_set_database, collation_database;log_mode 为 ARCHIVELOG 是基础前提supplemental_log_data_min 为 YES 才能保证日志解析出完整的更新前镜像。两段都通过后再启动任务realsync daemon start --conf ./task_ora2mysql.yaml realsync task start --name task_ora2mysql两个动作有先后daemon start 拉起 Realsync 的守护进程task start 让具体任务进入运行状态。多任务共用同一守护进程时要确认各任务的 queue_dir 不重叠避免 checkpoint 写入互相覆盖。3. Realsync 任务启停、参数调整与数据一致校验3.1 启停前先看位点和延迟再决定用 pause 还是 stopRealsync 任务运行中控制台能直接观察到源端日志位点和目标端接收位点。这里要养成的操作习惯是暂停前先查询状态记录当前位点再做动作。realsync task status --name task_ora2mysql --detail realsync task pause --name task_ora2mysql--detail 是这段命令的关键它会输出当前抓取位点、目标端回放位点和积压量。pause 是“暂停”而不是“停止”暂停时捕获进程保留现场队列文件不清理恢复后从暂停点继续stop 则会释放进程资源并关闭任务下次 start 时从 checkpoint 记录的位置重新初始化。提示需要维护目标库或调整表结构时优先用 pause 而不是 stop。stop 之后重新拉起如果 checkpoint 文件落盘时间和实际日志位置存在偏差会出现重复读取虽然 Realsync 的事务过滤机制能处理重复但无谓的重复解析会拖慢追平速度。确认延迟进入可接受范围后再执行 resume 恢复正常同步realsync task resume --name task_ora2mysql这一套动作的核心是把“操作”和“确认”分开先看状态再暂停最后核对恢复避免直接在业务高峰期硬停。3.2 运行时要调整的五个 Realsync 参数运行过程中绝大多数性能问题最后都会落到下面这张参数表上参数名建议范围作用适用判断batch_size1000-5000单个抓取批次行数大字段或长文本多时调小parallel_workers2-8目标端回放并行度目标端锁等待多时调小queue_dir 磁盘水位低于 70%队列可用空间目标故障期间持续增长tran_timeout30-120s长事务解析超时源端跑批任务期间调大log_levelinfo 或 debug日志输出详细度排障开 debug平时 infobatch_size 并非越大越好。它代表单批抓取的数据行数调大确实能减少线程切换但若一批数据里混合多个大事务内存占用会快速上升甚至触发操作系统 OOM。常见做法是从 1000 起步稳定运行后逐步上调并同时观察目标端的每秒写入量。parallel_workers 影响的是目标端回放。多数数据库在并发写入同一张表时锁等待会抵消并发收益尤其源端是单表单事务模型时盲目调高这个参数经常出现反效果。目标端是分库分表结构或存在多个任务分散到不同目标库时才适合把并行度往上推。3.2.1 tran_timeout 与长事务的取舍tran_timeout 描述单个事务允许解析的最大时间。业务侧跑批或做月度结算时源端可能出现持续几分钟的大事务如果这个参数还是默认的 30 秒任务会反复报事务超时实际数据没丢但日志里全是告警。遇到这类批量作业我一般先把 tran_timeout 调到 120 秒再观察一段时间确认没有新的超时报错后再结合实际问题决定是否维持该值。3.3 用 SQL 校验增量数据是否一致同步任务运行一段时间后最直接的验证方式不是只查 count而是用业务时间字段做交叉比较。下面两条 SQL 分别适用于源端 Oracle 和目标端 MySQL-- 源端 Oracle统计最近 2 小时的记录数和金额合计 select count(*), sum(amount) from app.orders where update_time sysdate - interval 2 hour; -- 目标端 MySQL相同时间窗口的数据统计 select count(*), sum(amount) from dsg_app.orders where update_time now() - interval 2 hour;count 判断是否有行丢失sum(amount) 判断是否存在更新未到位或重复写入。故意使用业务时间字段而不是数据库自带的物理位置或 rowid是因为异构库之间没有可比的物理标识。结果一致基本能确认最近两小时同步正常不一致时把时间窗口缩小到 15 分钟逐段比对能快速锁定差异区间再针对具体表主键检查单行数据。4. Realsync 日志定位、断点恢复与积压追赶4.1 分级日志定位法caputure 与 apply 分开看排障第一步永远是按环节定位而不是在一个文件里反复 grep。Realsync 通常会把捕获过程和回放过程分开记录日志两类日志的错误含义不同定位方向也不同。# 查看回放端最近 20 分钟是否有错误 grep $(date %Y-%m-%d\ %H:) logs/realsync_apply.log | grep -iE error|exception # 查看捕获端 checkpoint 是否还在推进 grep $(date %Y-%m-%d\ %H:) logs/realsync_capture.log | grep -i checkpointcapture 日志里有 checkpoint 推进说明源端解析正常apply 日志持续报错说明问题集中在目标端执行阶段。为了明确故障段可以按现象做对照故障现象优先查的日志优先排查方向源端有更新目标端完全不更新capture 日志日志模式、账号权限、queue 目录capture 正常apply 反复重试apply 日志数据约束、索引冲突、字符集两端都更新延迟持续变大队列日志大事务、带宽、并行度设置这个对照表的思路是顺着数据流逐段排除先确认捕获有没有读到日志再确认回放有没有被约束挡住最后才考虑性能问题。4.2 目标端约束冲突与回放中断的处理同步过程中目标端表经常有主键、唯一约束或外键如果业务系统在目标端手工改过数据或者让目标端也接收了其他应用写入回放事务就会和数据冲突。典型表现是 apply 日志里反复出现主键冲突但源端并没有删除该行。恢复思路如下-- 在目标端临时关闭外键检查仅用于测试环境定位 SET FOREIGN_KEY_CHECKS 0; -- 生产环境优先找出冲突行再对比两端记录 select id, update_time from dsg_app.orders where id 100010;临时关闭外键检查只适合验证问题是否由外键引起生产环境不能当长期方案。正确做法是让目标表成为同步专用表禁止应用直接写入如果确有并发写入需求就从模型层面把目标端拆成多套 schema 隔离从机制上避免冲突。4.2.1 手工修补与表级重建的边界当冲突行是源库存在但目标库被人为改坏时不需要重建整张表把源端对应行的最新数据单独补到目标端即可若冲突行数过多执行表级重建更稳妥realsync task stop --name task_ora2mysql --table app.orders realsync task reinit --name task_ora2mysql --table app.orders --mode snapshot realsync task start --name task_ora2mysqlreinit 表示对该表做全量快照重建执行完成后自动切回增量同步。这个命令是有损操作使用前必须确认只有这一张表需要重建并提前记录重建前后的位点便于回退对比。4.3 归档日志被清理后的恢复与积压追赶源端日志保留时间不足是 Realsync 运维里比较典型的隐患。如果捕获进程需要的归档日志已经被清理任务会进入等待状态且无法推进。此时若目标端数据不允许全面重灌按优先级做分段补数对能接受快照的表执行 reinit快速恢复近期数据对无法中断的大表先在源端导出该表数据再导入目标端尽量保持原主键不变补数完成后重新打开该表对应的同步任务并确认 checkpoint 已跳过已被手工覆盖的区间。恢复期间要注意reinit 和手工导入都必须避开源端业务高峰否则全量扫描会放大源库负载。追赶积压时可以在确认目标库 IO 有余量的前提下临时提高 parallel_workers但任务追平后要立刻调回原值避免影响目标库日常业务。5. Realsync 十分钟巡检与增量追平技巧5.1 把 Realsync 状态检查固化成定时命令有一定运维积累之后可以把巡检固定成一组命令每次只做四件事查进程状态、看位点差值、看队列磁盘水位、过滤最近一段时间的错误日志。realsync task status --name task_ora2mysql --detail df -h /data/rs_queue | tail -1 grep $(date %Y-%m-%d\ %H:) logs/realsync_apply.log | grep -i error | tail -20把这三条命令放入一个 shell 脚本配合 crontab 每 5 分钟执行一次输出追加到固定文件就能形成低成本的监控基线。需要避开的坑是巡检脚本里不要放 stop、reinit 这类变更动作巡检的意义是发现问题不是自动解决问题自动恢复动作应该放到经过评审的故障预案里由人触发执行。5.2 大事务积压场景下的安全追平技巧当延迟来自某张超大表的批量更新时不要只调高并行度。先把该表从任务中临时摘除让任务继续处理其余小事务再为这张表单独执行一次 reinit避免大事务挤占队列处理窗口让其他表的同步先恢复正常最后再把这大表的数据重新对齐。提示任何涉及 reinit 或摘除表的操作执行前都把 checkpoint 文件和位点信息复制一份到备份目录避免操作失误后失去回退依据。这种逐表处理的策略比整体调高 parallel_workers 更可控因为它不会影响目标端整体负载也不会在并行线程之间引入锁竞争。把巡检命令、位点记录和补数策略固定成规范动作后维护重点就从“能不能同步”转移到“怎样在故障时快速恢复”这也是 Realsync 长期稳定运行的核心能力。本文还有配套的精品资源点击获取 Realsync数据库同步运维实战：日志解析、断点续传与调优
简介DSG Realsync管理维护手册是一份面向数据库管理员和运维人员的实操型技术文档聚焦迪思杰Realsync在不同数据库之间实现实时数据同步的部署、配置与维护尤其适合初次接触或正在评估该复制工具的团队。资源为单份DOC文档共49页压缩包约350KB轻量易携带可作为同步复制工具的手边速查手册。手册完整涵盖REALSYNC工作原理日志抓取、日志分析、交易合成、交易传输、数据装载、复制关系维护与首次全同步流程、DML/DDL操作复制支持情况及常见不支持操作的处理建议、各复制端口一览表并详细说明软件部署结构与源端/目标端安装目录中config、scripts、bin、log、rmp等重点文件的作用帮助管理员从日志级复制原理逐层理解系统架构与实际配置。内容按复制流程、支持能力、端口配置、部署结构逐层展开便于按需查阅。已有121人学习对需要维护跨库数据一致性的团队而言这份手册能显著降低学习门槛提升数据库同步的排障效率。1. 理解 DSG Realsync 在实时数据同步链路中的角色DSG Realsync 是一款以数据库日志解析为核心的实时同步软件主要解决同构或异构数据库之间的数据实时复制问题。很多 DBA 第一次碰到它是在做数据分发、读写分离或容灾切换的时候它不依赖业务系统改造也不要求在应用里写双写逻辑而是直接从源库日志里捕获事务再按提交顺序投递到目标库。这一点让它在运维侧的定位和 ETL 工具明显不同ETL 关心“一批数据对不对”Realsync 这类工具更关心“这条事务到底有没有在目标端生效”。因此实际难点往往不在安装而在配置阶段的位点理解、运行阶段的状态判断、故障阶段的断点恢复。下面按部署检查、任务配置、运行管理、排障恢复和巡检优化来展开一套可复用的维护打法。2. Realsync 部署前置检查与配置参数准备2.1 理解 Realsync 的进程模型采集、传输、回放DSG Realsync 做同步时不会反复对源库执行查询来“找出变化”而是从数据库日志里读取已提交事务。以常见流程为例一条完整同步链路至少包含三个环节源端捕获进程读取在线日志或归档日志把事务解析为内部记录并写入本地队列文件传输进程负责把队列内容分发到目标端目标端的应用进程再按事务先后顺序写入目标数据库。三者之间通过记录位点的 checkpoint 文件保持衔接这也是 Realsync 能实现断点续传的基础。部署前要对这三个环节分别预留资源。捕获进程所在主机重点看磁盘空间和 IO 能力因为队列文件会落到本地磁盘传输环节受网络带宽和两端防火墙影响目标端应用进程需要关注数据库的表结构、约束和字符集。很多初次使用的人把精力集中在数据库连接参数上却忽略了队列目录的磁盘水位一旦目标端故障持续数小时队列积压很容易把磁盘写满。2.1.1 一条同步链路的角色与规划要点下表是部署时通常需要确认的内容链路角色承担工作资源规划要点源端捕获进程日志读取、事务解析日志目录空间、CPU、归档模式本地队列与传输进程数据缓存、网络分发队列磁盘水位、带宽、防火墙目标端应用进程事务回放、约束检查目标库 IO、索引、字符集表里三行的顺序同样代表数据流向排障时先判断故障落在这三段里的哪一段再决定下一步去翻哪类日志而不是一上来就怀疑网络或数据库参数。2.2 一份同步任务配置里的三类参数Realsync 的任务配置在不同版本里格式不完全一致但核心字段基本固定常见做法是把源端连接、目标端连接、同步选项分开维护。这里给出一次任务配置时典型的 YAML 风格字段task: name: task_ora2mysql # 控制台和日志中的任务标识 source: db_type: oracle host: 10.10.1.10 port: 1521 service_name: ORCL user: rs_capture password: ENC(省略) log_mode: archive # archive 表示解析归档日志 target: db_type: mysql host: 10.10.1.30 port: 3306 schema: dsg_app user: rs_apply password: ENC(省略) charset: utf8mb4 # 目标端字符集异构时必填 sync: tables: app.orders,ods.* # 按表名或模式匹配 batch_size: 2000 # 每个批次抓取的行数 parallel_workers: 4 # 目标端回放并行度 queue_dir: /data/rs_queue # 本地队列目录 log_level: info # 排障时可临时调成 debugsource 和 target 两段要注意两个坑。第一源端账号不只是能查询数据还需要具备读取日志位点的权限否则任务反复处于等待日志状态。第二异构同步场景下目标端 charset 如果和源端字符集对不上回放时可能并不报错但数据会乱码或长度溢出这类问题往往跑数小时才暴露定位成本很高。sync 段里的 batch_size 是典型的性能拐点。批量抓取行数越大单位时间解析的事务越多但每批事务在目标端提交时的开销也越大遇到大字段多的表反而会因为单批数据过大拖慢回放。parallel_workers 则决定目标端回放的并发线程数后面会专门说这组参数的调整方向。2.3 启动 Realsync 前的最小链路验证配置完成后不要直接启动整个任务先把两端的连通性和账号权限验一遍。我一般会用下面的命令检查网络和端口nc -zv 10.10.1.10 1521 nc -zv 10.10.1.30 3306第一行测试源端 Oracle 的 1521 端口是否能建立 TCP 连接第二行测试目标端 MySQL 的 3306 端口。这一步能避免把网络禁 ping、防火墙丢包等问题误判成同步软件故障。数据库账号的验证则要实际连库执行查询-- 源端 Oracle 查看日志模式 select log_mode, supplemental_log_data_min from v$database; -- 目标端 MySQL 确认库可写、字符集一致 select character_set_database, collation_database;log_mode 为 ARCHIVELOG 是基础前提supplemental_log_data_min 为 YES 才能保证日志解析出完整的更新前镜像。两段都通过后再启动任务realsync daemon start --conf ./task_ora2mysql.yaml realsync task start --name task_ora2mysql两个动作有先后daemon start 拉起 Realsync 的守护进程task start 让具体任务进入运行状态。多任务共用同一守护进程时要确认各任务的 queue_dir 不重叠避免 checkpoint 写入互相覆盖。3. Realsync 任务启停、参数调整与数据一致校验3.1 启停前先看位点和延迟再决定用 pause 还是 stopRealsync 任务运行中控制台能直接观察到源端日志位点和目标端接收位点。这里要养成的操作习惯是暂停前先查询状态记录当前位点再做动作。realsync task status --name task_ora2mysql --detail realsync task pause --name task_ora2mysql--detail 是这段命令的关键它会输出当前抓取位点、目标端回放位点和积压量。pause 是“暂停”而不是“停止”暂停时捕获进程保留现场队列文件不清理恢复后从暂停点继续stop 则会释放进程资源并关闭任务下次 start 时从 checkpoint 记录的位置重新初始化。提示需要维护目标库或调整表结构时优先用 pause 而不是 stop。stop 之后重新拉起如果 checkpoint 文件落盘时间和实际日志位置存在偏差会出现重复读取虽然 Realsync 的事务过滤机制能处理重复但无谓的重复解析会拖慢追平速度。确认延迟进入可接受范围后再执行 resume 恢复正常同步realsync task resume --name task_ora2mysql这一套动作的核心是把“操作”和“确认”分开先看状态再暂停最后核对恢复避免直接在业务高峰期硬停。3.2 运行时要调整的五个 Realsync 参数运行过程中绝大多数性能问题最后都会落到下面这张参数表上参数名建议范围作用适用判断batch_size1000-5000单个抓取批次行数大字段或长文本多时调小parallel_workers2-8目标端回放并行度目标端锁等待多时调小queue_dir 磁盘水位低于 70%队列可用空间目标故障期间持续增长tran_timeout30-120s长事务解析超时源端跑批任务期间调大log_levelinfo 或 debug日志输出详细度排障开 debug平时 infobatch_size 并非越大越好。它代表单批抓取的数据行数调大确实能减少线程切换但若一批数据里混合多个大事务内存占用会快速上升甚至触发操作系统 OOM。常见做法是从 1000 起步稳定运行后逐步上调并同时观察目标端的每秒写入量。parallel_workers 影响的是目标端回放。多数数据库在并发写入同一张表时锁等待会抵消并发收益尤其源端是单表单事务模型时盲目调高这个参数经常出现反效果。目标端是分库分表结构或存在多个任务分散到不同目标库时才适合把并行度往上推。3.2.1 tran_timeout 与长事务的取舍tran_timeout 描述单个事务允许解析的最大时间。业务侧跑批或做月度结算时源端可能出现持续几分钟的大事务如果这个参数还是默认的 30 秒任务会反复报事务超时实际数据没丢但日志里全是告警。遇到这类批量作业我一般先把 tran_timeout 调到 120 秒再观察一段时间确认没有新的超时报错后再结合实际问题决定是否维持该值。3.3 用 SQL 校验增量数据是否一致同步任务运行一段时间后最直接的验证方式不是只查 count而是用业务时间字段做交叉比较。下面两条 SQL 分别适用于源端 Oracle 和目标端 MySQL-- 源端 Oracle统计最近 2 小时的记录数和金额合计 select count(*), sum(amount) from app.orders where update_time sysdate - interval 2 hour; -- 目标端 MySQL相同时间窗口的数据统计 select count(*), sum(amount) from dsg_app.orders where update_time now() - interval 2 hour;count 判断是否有行丢失sum(amount) 判断是否存在更新未到位或重复写入。故意使用业务时间字段而不是数据库自带的物理位置或 rowid是因为异构库之间没有可比的物理标识。结果一致基本能确认最近两小时同步正常不一致时把时间窗口缩小到 15 分钟逐段比对能快速锁定差异区间再针对具体表主键检查单行数据。4. Realsync 日志定位、断点恢复与积压追赶4.1 分级日志定位法caputure 与 apply 分开看排障第一步永远是按环节定位而不是在一个文件里反复 grep。Realsync 通常会把捕获过程和回放过程分开记录日志两类日志的错误含义不同定位方向也不同。# 查看回放端最近 20 分钟是否有错误 grep $(date %Y-%m-%d\ %H:) logs/realsync_apply.log | grep -iE error|exception # 查看捕获端 checkpoint 是否还在推进 grep $(date %Y-%m-%d\ %H:) logs/realsync_capture.log | grep -i checkpointcapture 日志里有 checkpoint 推进说明源端解析正常apply 日志持续报错说明问题集中在目标端执行阶段。为了明确故障段可以按现象做对照故障现象优先查的日志优先排查方向源端有更新目标端完全不更新capture 日志日志模式、账号权限、queue 目录capture 正常apply 反复重试apply 日志数据约束、索引冲突、字符集两端都更新延迟持续变大队列日志大事务、带宽、并行度设置这个对照表的思路是顺着数据流逐段排除先确认捕获有没有读到日志再确认回放有没有被约束挡住最后才考虑性能问题。4.2 目标端约束冲突与回放中断的处理同步过程中目标端表经常有主键、唯一约束或外键如果业务系统在目标端手工改过数据或者让目标端也接收了其他应用写入回放事务就会和数据冲突。典型表现是 apply 日志里反复出现主键冲突但源端并没有删除该行。恢复思路如下-- 在目标端临时关闭外键检查仅用于测试环境定位 SET FOREIGN_KEY_CHECKS 0; -- 生产环境优先找出冲突行再对比两端记录 select id, update_time from dsg_app.orders where id 100010;临时关闭外键检查只适合验证问题是否由外键引起生产环境不能当长期方案。正确做法是让目标表成为同步专用表禁止应用直接写入如果确有并发写入需求就从模型层面把目标端拆成多套 schema 隔离从机制上避免冲突。4.2.1 手工修补与表级重建的边界当冲突行是源库存在但目标库被人为改坏时不需要重建整张表把源端对应行的最新数据单独补到目标端即可若冲突行数过多执行表级重建更稳妥realsync task stop --name task_ora2mysql --table app.orders realsync task reinit --name task_ora2mysql --table app.orders --mode snapshot realsync task start --name task_ora2mysqlreinit 表示对该表做全量快照重建执行完成后自动切回增量同步。这个命令是有损操作使用前必须确认只有这一张表需要重建并提前记录重建前后的位点便于回退对比。4.3 归档日志被清理后的恢复与积压追赶源端日志保留时间不足是 Realsync 运维里比较典型的隐患。如果捕获进程需要的归档日志已经被清理任务会进入等待状态且无法推进。此时若目标端数据不允许全面重灌按优先级做分段补数对能接受快照的表执行 reinit快速恢复近期数据对无法中断的大表先在源端导出该表数据再导入目标端尽量保持原主键不变补数完成后重新打开该表对应的同步任务并确认 checkpoint 已跳过已被手工覆盖的区间。恢复期间要注意reinit 和手工导入都必须避开源端业务高峰否则全量扫描会放大源库负载。追赶积压时可以在确认目标库 IO 有余量的前提下临时提高 parallel_workers但任务追平后要立刻调回原值避免影响目标库日常业务。5. Realsync 十分钟巡检与增量追平技巧5.1 把 Realsync 状态检查固化成定时命令有一定运维积累之后可以把巡检固定成一组命令每次只做四件事查进程状态、看位点差值、看队列磁盘水位、过滤最近一段时间的错误日志。realsync task status --name task_ora2mysql --detail df -h /data/rs_queue | tail -1 grep $(date %Y-%m-%d\ %H:) logs/realsync_apply.log | grep -i error | tail -20把这三条命令放入一个 shell 脚本配合 crontab 每 5 分钟执行一次输出追加到固定文件就能形成低成本的监控基线。需要避开的坑是巡检脚本里不要放 stop、reinit 这类变更动作巡检的意义是发现问题不是自动解决问题自动恢复动作应该放到经过评审的故障预案里由人触发执行。5.2 大事务积压场景下的安全追平技巧当延迟来自某张超大表的批量更新时不要只调高并行度。先把该表从任务中临时摘除让任务继续处理其余小事务再为这张表单独执行一次 reinit避免大事务挤占队列处理窗口让其他表的同步先恢复正常最后再把这大表的数据重新对齐。提示任何涉及 reinit 或摘除表的操作执行前都把 checkpoint 文件和位点信息复制一份到备份目录避免操作失误后失去回退依据。这种逐表处理的策略比整体调高 parallel_workers 更可控因为它不会影响目标端整体负载也不会在并行线程之间引入锁竞争。把巡检命令、位点记录和补数策略固定成规范动作后维护重点就从“能不能同步”转移到“怎样在故障时快速恢复”这也是 Realsync 长期稳定运行的核心能力。本文还有配套的精品资源点击获取