简介DBSyncer简称dbs是一款面向数据库管理员、运维及后端开发者的开源数据同步中间件聚焦MySQL、Oracle、SqlServer、PostgreSQL、Elasticsearch、Kafka、File、SQL等异构数据源之间的实时同步与转换场景特别适合需要处理多库迁移、增量采集、插件化自定义同步业务的中大型数据平台。资源内含完整项目文件共737个文件、压缩包约2.07MB其中472个java源码覆盖核心同步逻辑81个png、59个css、42个html及36个js构成可视化监控前端15个xml与5个sql提供配置模板与初始化示例另附sh、cmd启动脚本便于本地快速部署体验。已有747人学习下载适合从入门到二次开发阶段循序渐进地研究。借助该资源读者可直接查看全量与增量同步统计图、性能预警功能的实现思路并基于自有场景修改同步逻辑或上传自定义插件降低自研数据同步模块的试错成本。1. 数据同步中间件不是定时任务DBSyncer 解决的事与适用场景DBSyncer简称 dbs这类数据同步中间件几乎每个做数据平台的人都绕不开一个困惑明明用 Cron 定时拉取加自增主键也能同步为什么还要引入一套专门系统答案是删除、更新、DDL 变更这些操作离线拉取永远对不上账。DBSyncer 把全量初始化、增量捕获、字段转换、目标端写入收进一个 Web 管理界面同时覆盖 MySQL、Oracle、SqlServer、PostgreSQL、Kafka、File、SQL 这些常见场景增量部分通过读取数据库日志如 MySQL binlog来感知而不是轮询业务表。它适合经常在异构数据库之间搬数据的 DBA、要给多套业务库做集中汇聚的数据工程师以及正在做同步中间件选型的技术负责人。2. 部署前先摸清发行包目录结构、启动入口与 JMX 监控配套2.1 解压后到底有什么从一堆静态资源里分清主次发行包解压后第一眼看到的往往是 bootstrap.min.css、font-awesome.min.css、_all.css 这堆前端静态资源很容易误以为是个纯 Web 展示项目。实际上这些 CSS 只是管理控制台的皮肤真正需要优先关注的是下面这几个文件。下表列出发行包里你最先要认清楚的几个文件这个顺序也是我每次部署时的检查顺序文件作用什么时候用startup.batWindows 下拉起 Java 进程的启动脚本日常启动、重启version.cmd查看当前发行版本号核对线上版本、排查是否拿错包build.cmd构建入口通常用于编译打包插件需要上传自定义转换插件时jmxremote.access控制 JMX 远程监控的读写权限配监控、暴露性能指标时如果你在 Linux 上部署一般会有对应的 .sh 脚本逻辑一致。另外 _all.css 这类合并压缩样式文件是前端构建产物不用修改也别看到报错就想去改它问题基本不在前端。2.2 启动入口与验证startup.bat 之外的检查手段先把 Java 环境确认掉。DBSyncer 是 Java 进程通常要求 JDK 8 及以上且解压路径不要带中文和空格。Windows 上第一次启动建议在前台跑一次别直接双击就完事——如果端口被占用或 JDK 位数不对窗口会一闪而过什么都看不见。前台跑能看到完整的控制台输出。cd D:\dbsyncer startup.bat第一次前台启动的目的是看两件事一是是否出现明显的启动异常堆栈二是管理端口到底落在哪个数字上。常见的默认管理端口一般是 8080但如果你本机已经装了其它 Web 服务启动时会有 java.net.BindException 之类的报错。这时候先看端口监听情况再决定改哪个配置netstat -ano | findstr 8080 tasklist | findstr javaLinux 部署时我一般把日志重定向到固定文件方便后面反复排查nohup ./startup.sh /data/logs/dbsyncer.log 21 tail -f /data/logs/dbsyncer.log日志里出现管理地址访问提示或者看到类似 Started Application 的关键字进程就算起来了。如果一直起不来优先检查 JAVA_HOME 是否指向正确版本以及 32 位 JDK 跑大堆内存配置导致的内存分配失败这两类问题占启动失败的一大半。2.3 为什么前置一副 JMX 监控配置它和性能预警是配套的jmxremote.access 这个文件容易被忽略但它恰恰是后面配置「应用性能预警」的基础。DBSyncer 管理界面里展示的 CPU、堆内存、GC 等应用指标多数是通过 JMXJava Management Extensions从运行中的 JVM 读出来的。默认情况下远程 JMX 是关闭的你需要在启动脚本里打开它并固定端口否则每次重启后端口随机监控配置就白做了。JAVA_OPTS-Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port7091 \ -Dcom.sun.management.jmxremote.authenticatefalse \ -Dcom.sun.management.jmxremote.sslfalse提示生产环境建议把 authenticate 设为 true配合 jmxremote.access 和 jmxremote.password 做权限控制只给运维账号只读权限。打开 JMX 后用 JConsole 连上 7091 端口就能直接看到堆内存曲线和 GC 频率。这个信息很重要——同步链路延迟时你能靠它区分到底是应用卡了还是源库和目标端链路本身慢而不是凭感觉重启。3. 把 MySQL、SQL Server 先接进来连接参数、驱动选型与测试失败排查3.1 管理台里一个数据源要填什么从驱动到连接参数DBSyncer 的数据源配置页核心字段其实比想象中少。连接类型、JDBC URL、用户名、密码加上驱动类名和连接池参数这六项决定了一个数据源能否被正常读写。很多人填完 URL 和密码就急着点测试结果连接失败多半是驱动类和连接池参数没对上。下面这组参数是我在 MySQL 8.0 场景下常用的基准值字段含义也一并列出来配置项常用值说明连接类型mysql决定引擎加载哪套驱动适配器驱动类com.mysql.cj.jdbc.DriverMySQL 8 以上用 cj 版5.x 用旧版用户名 / 密码按源库账密填写增量同步还需要 REPLICATION 权限initialSize2启动时建立的初始连接数maxActive20最大活跃连接数全量大批量时看这里validationQuerySELECT 1连接有效性探活语句连接池参数很多人不调全量同步一跑起来就报连接不够或者长时间空闲后被源库踢掉。有过这类经验的人会提前把 maxActive 调大一点并保证 validationQuery 能快速返回探活语句尽量选最简单的不要查大表。3.2 不同数据库的 Driver 与 JDBC URL 怎么写不同数据库的 JDBC URL 语法差别不小尤其是 Oracle 和 SQL Server很多人第一次接就栽在 URL 格式上。我把四类常见库的拼法整理成一张表这里面的驱动类名也一并给出方便你在驱动管理里核对。数据库JDBC URL 模板驱动类MySQLjdbc:mysql://host:3306/db?useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstruecom.mysql.cj.jdbc.DriverSQL Serverjdbc:sqlserver://host:1433;DatabaseNamebiz;encryptfalse;trustServerCertificatetruecom.microsoft.sqlserver.jdbc.SQLServerDriverOraclejdbc:oracle:thin://host:1521/service_nameoracle.jdbc.OracleDriverPostgreSQLjdbc:postgresql://host:5432/dborg.postgresql.DriverMySQL 的 URL 里我特意加了三个参数useSSLfalse 省去内网握手开销serverTimezone 固定时区避免日期字段偏移rewriteBatchedStatementstrue 在批量写入时能把多条 insert 合并全量初始化阶段吞吐提升非常明显。SQL Server 的 encryptfalse 解决的是内网 TLS 握手导致的连接超时问题trustServerCertificate 配合使用。Oracle 这里建议用 //host:1521/service_name 这种服务名写法比老式 SID 写法更容易兼容 RAC 环境。驱动 jar 的放置位置也要检查光在页面里填了驱动类名但 jar 没进驱动目录连接测试照样失败。不同版本驱动兼容性差异明显比如老 mssql-jdbc 对高版本 SQL Server 的 TLS 协议支持不好这类问题在 3.3 节细说。3.3 连接测试失败的常见原因现象、原因与处理数据源配置完点「测试连接」是最快也最暴露问题的一步。这里写三个我反复遇到的典型失败场景。场景一MySQL 8 报 Public Key Retrieval is not allowed。原因是 MySQL 8 默认用 caching_sha2_password 认证非 SSL 连接下需要获取 RSA 公钥。解决办法是在 URL 里加 allowPublicKeyRetrievaltrue。它看起来像安全降级但内网数据同步场景下是常见做法公网环境另说。场景二SQL Server 连接超时日志里出现 TLS/SSL 相关报错。原因是新版 SQL Server 默认强制加密而驱动和实例之间的协议协商失败。先在 URL 里显式声明 encryptfalse;trustServerCertificatetrue如果还不行检查 mssql-jdbc 版本是否太老按微软支持矩阵换到对应版本。我见过因为驱动 jar 还是 6.x 导致连接失败的换成 9.x 后恢复。场景三Oracle 报 ORA-12514连接串写的是 host:1521:SID 形式而目标实例注册的是服务名。把 URL 改成 //host:1521/service_name 一般就通了。如果仍连不上用 tnsping 类似的网络工具确认目标端口通不通排查顺序别反了。# 确认端口能通再做驱动和 URL 的排查 telnet 10.0.0.10 1521 telnet 10.0.0.11 33064. 建一条 MySQL→Kafka 同步链路同步器配置、全量/增量触发与映射边界4.1 同步器的四个组成驱动、表、映射和目标端数据源注册只是第一步真正干活的是「同步器」。同步器把来源驱动、目标驱动、字段映射和同步策略四部分绑在一起相当于告诉引擎从哪读、写到哪、字段怎么转换、用全量还是增量方式跑。我习惯在动手配之前先把这四个问题写在纸上免得界面上点着点着就乱。来源驱动决定了引擎用什么方式读数据。MySQL 走 binlog 订阅SQL Server 走 CDC 或日志读取Oracle 走 Redo Log 相关机制目标端是 Kafka 时引擎负责把变更记录序列化成消息写到指定 topic目标端是 File 时则生成约定格式的数据文件。字段映射解决的是源表和目标结构不一致的问题——比如源库叫 user_name下游要求 username字段名就要在映射里显式改掉。4.2 一个「表级同步 字段清洗」的配置示例下面是一个 MySQL 表同步到 Kafka 的配置结构。不同版本界面导出的字段名可能有差异重点是理解结构中的四段source、target、mapping、strategy。{ name: mysql_user_to_kafka, source: { type: mysql, refId: dataSource_id_of_biz_db, table: app_user, sql: SELECT id, user_name, nickname, status, update_time FROM app_user WHERE status 1 }, target: { type: kafka, bootstrapServers: 10.0.0.5:9092,10.0.0.6:9092, topic: sync_app_user, ack: all, serializer: jsonString }, mapping: { id: id, user_name: username, nickname: nickname, status: status, update_time: updateTime }, strategy: { full: true, incremental: true, intervalMs: 3000 } }source 里的 sql 是 SQL 同步场景的入口。写带 WHERE 的查询引擎会按这条 SQL 拉取数据如果不写 sql 只写 table则走标准表级同步。target 里的 bootstrapServers 一定要把 Kafka 集群所有 broker 地址都写上只填一个节点虽然能连但该节点临时不可用时会直接断链。ack 设成 all 是至少保住消息不丢的底线顺序敏感业务尤其不能省。mapping 里的 key 是源字段value 是目标端字段实现字段重命名的同时也可以做裁剪——比如把不想暴露的字段直接从映射里去掉。strategy 里的 full 和 incremental 分别控制是否允许全量初始化、是否开启增量捕获intervalMs 是增量轮询或状态刷新的周期生产环境我一般不会低于 3000太小的间隔只会增加无谓开销。4.3 全量和增量怎么触发增量捕获与断点记录全量同步的逻辑比较直接引擎按主键或分页把源表当前快照拉到目标端适合第一次初始化或重建数据。你可以在管理台手动触发跑完后看统计图里的全量记录数是否和源表行数吻合。增量同步则是 DBSyncer 这类中间件区别于定时任务的关键。MySQL 场景下引擎会订阅源库 binlog把 insert、update、delete 事件解析后按映射规则写入目标端。前提是源库已经开启 binlog并且格式为 ROW。启动增量之前建议先在源库确认下面几个变量-- 源端 MySQL 检查增量前提 SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format; SHOW VARIABLES LIKE binlog_row_image;log_bin 必须为 ONbinlog_format 必须是 ROWSTATEMENT 格式记录的是 SQL 语句无法可靠还原字段级变更binlog_row_image 建议为 FULL这样 UPDATE 时能拿到变更前后的完整字段。断点一般记录在引擎自身的状态存储里重启后从断点续传不会重头再来这点比定时任务可靠得多。4.4 表结构变更、主键缺失等选型边界用这个中间件时有一些边界要提前知道。源表没有主键全量分页会不稳定增量同步在部分数据库上也可能直接不支持我一般会先和业务方确认能否补主键不能补就只做基于时间字段的增量查询方案。目标表不存在时跨库自动建表的 DDL 兼容性很差SQL Server 的 nvarchar 和 MySQL 的 utf8mb4 在字符集换算上经常不一致更稳妥的做法是先在目标端手工建好表再回来配映射。Kafka 作为目标端时要特别注意顺序问题。多分区下消息无法保证全局有序业务如果要求严格按主键顺序消费topic 分区数建议设为 1或者在消息体里带上主键字段允许最终一致的大多数场景按业务主键做 hash 分区就够用了。大表全量初始化不要把压力全压在业务高峰期时间切片分批跑或者干脆低峰期初始化。5. 避坑同步数据前先排掉这五个高频故障5.1 MySQL 增量不触发先查 binlog 格式现象全量同步正常配置完增量后管理台一直显示等待新日志记录数纹丝不动。原因源库没开 binlog或者 binlog_format 不是 ROW也可能是同步账号缺 REPLICATION SLAVE 权限。解决先跑一遍前面 4.3 节的那三条 SHOW 语句确认然后补权限和格式。-- 增量账号至少要有 SELECT、REPLICATION SLAVE、REPLICATION CLIENT GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO dbsync%;改完 binlog_format 之后注意已有连接的 binlog 格式不会立即生效需要重连会话或重启 MySQL 实例这一步是最容易忽略的。我曾经在这上面浪费过一下午改完配置发现增量还是不动重新建立同步会话后才恢复。5.2 SQL Server 同步慢或日志读取报错代理、主键和驱动版本现象SQL Server 数据源测试通过全量也能跑但增量部分没有反应后台日志出现关于日志读取或 CDC 的报错。原因SQL Server 的增量捕获依赖 SQL Server Agent 服务Agent 没启动日志读取就无从谈起另外源表没有主键日志捕获也无法正常标记变更行。解决先确认 SQL Server Agent 处于运行状态再给源表补主键最后检查 mssql-jdbc 驱动版本是否过老老驱动连新实例的 TLS 加持会握手失败。5.3 Oracle 连上但增量没数据补充日志与驱动匹配现象Oracle 数据源测试连接通过同步器配好之后增量长期是 0 条。原因Oracle 的增量机制依赖 Redo Log库上没有开补充日志或者同步账号缺少相关权限驱动 jar 版本和数据库版本不匹配也会静默失败。解决在源库执行最小补充日志开启语句并授予同步账号足够的日志读取权限。-- 开启最小补充日志Oracle 增量同步的前提 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;驱动方面连接 11g 和 19c 需要的 ojdbc 版本不一样别只盯着「能连上」就以为万事大吉连得上和读得到日志是两回事。5.4 Kafka 目标端延迟高与消息顺序问题现象源端一直在读但管理台上 Kafka 目标的写入记录数增长缓慢或者下游消费时发现顺序乱了。原因bootstrapServers 只填了一个 broker恰好这个节点被访问时转发能力受限或者目标 topic 分区数太多引擎并行发送后无法保证全局顺序ack 设置不当还可能丢消息。解决bootstrapServers 写全所有 broker 地址顺序敏感场景把分区数设为 1 并开 ackall同时把 batch.size 和 linger.ms 调到合适的值避免为了吞吐把消息攒太久。5.5 时间字段偏移和中文乱码时区与字符集要提前定现象同步过去的时间字段比源库早了或晚了若干小时中文内容变成问号。原因JDBC URL 没设置 serverTimezone默认时区和你应用所在时区不一致源库表是 utf8mb4目标端建表用了 latin1转换时直接丢字符File 同步场景则是文件读写编码没指定。解决URL 里统一带 serverTimezoneAsia/Shanghai目标表字段显式指定 utf8mb4File 场景在连接配置里指定 charsetUTF-8。这类问题一旦数据写进去了再修成本很高上线前就把时区和编码核对清楚。6. 上线前的最后一步看统计图、定预警阈值、挂插件再验收链路链路跑起来后的运维重点其实只有三件事看统计图、管预警、留扩展能力。全量记录数代表初始化吞吐增量行数曲线平滑说明 binlog 消费健康如果增量曲线出现断崖或者长期为零优先查源端日志和断点状态而不是盲目重启同步器。我一般会把统计图截图留档每次变更映射或目标结构后对比一次曲线能快速发现隐性故障。预警这块直接在管理台把阈值设出来别等告警邮件变成半夜电话。预警项建议阈值说明应用 CPU 使用率80% 持续 5 分钟超过后先看是不是有大批全量任务堆内存使用率85%配合 JConsole 看 GC 频率任务积压批次1000 以上积压持续上涨说明消费端有问题单次同步延迟30 秒超过后结合源库负载判断插件扩展是 DBSyncer 的一个实用点。加密字段、状态枚举翻译、敏感列脱敏这类同步转换不必改引擎代码写一个实现转换接口的 jar用 build.cmd 编译打包后在插件管理里上传重新启动同步器后映射里就能选到新转换器。这比在同步链路后面再挂一套清洗程序省事得多。我自己的习惯是每次上线新链路都强制按「全量初始化 → 停源写入 → 增量验证」的顺序走一遍先全量灌数据然后让业务方配合停写几分钟开启增量后再手动造一条更新数据看统计图有没有即时跳动。断点位置和 JMX 端口写进运维台账而不是记在自己脑子里。这套流程跑顺之后夜里被叫起来的次数明显少了。希望帮到你。本文还有配套的精品资源点击获取