Dbsyncer实战：MySQL全量同步与增量同步配置指南

Dbsyncer这个开源数据同步中间件，最近在圈子里聊得不少。简单说，它是一个带Web管理界面的数据同步工具，不写代码、不装客户端，浏览器里点点点就能把MySQL的数据同步到另一个MySQL或者其他数据库。我这次带大家玩一下最常见的场景：MySQL to MySQL，把全量同步和增量同步的配置路径完整走一遍。

为什么会对这玩意儿感兴趣？平时工作里数据同步的需求实在太多了。从生产库抽一份数据到测试环境跑集成测试、把业务库的数据汇总到报表库做分析、或者给某个新系统初始化数据，都属于这个范畴。以前我拿DataX做批量同步，拿Canal做增量监听，两套工具来回切换，配置分散，监控还得自己拼。Dbsyncer把全量和增量统一到一个界面里做，开箱即用，对中小团队来说算挺省事的方案。

这篇文章适合谁？想把数据同步这摊子事快速搞定、又不想啃一堆框架源码的人。从部署到配置，从全量到增量，我会把整个链路和踩过的坑一起讲清楚。

1. 整体设计与方案选型：为什么Dbsyncer能一站搞定

1.1 一个界面管全量管增量，架构思路拆解

Dbsyncer的架构，拆开看其实不复杂。最上层是Web管理控制台，负责配置同步连接器、同步映射、同步任务，把用户的操作持久化到内置的系统库里。中间层是调度与执行引擎，负责把同步任务分发出去，处理全量同步的批读批写、增量同步的日志监听。最下面是各种插件，比如MySQL插件、Oracle插件、SQL Server插件，每个插件封装了对应数据库的驱动和同步逻辑。

这个分层设计带来一个很直接的好处：用户不碰代码，只要填表单就能定义“从哪张表、到哪张表、怎么同步”。我做数据迁移也写过一次性脚本，那种方式看着灵活，但每次换场景都要改代码、重新调试，维护成本很高。Dbsyncer把同步过程抽象成“连接器+映射+任务”三个层次，等于把可复用的部分全部模板化了。

另外，插件机制也为后续扩展数据库类型留了余地。今天你从MySQL同步到MySQL，明天可能要从Oracle同步到PostgreSQL，只要装对应的插件，同步链路的配置方式基本不变，学习成本是收敛的。

1.2 对比DataX和Canal，选型逻辑是什么

我不是第一次做数据同步。以前用DataX做批量同步，DataX在离线批量同步领域做得稳，吞吐量、断点续传都不错，但它本质上是一个跑批工具，没法实时监听数据库变更。要实时同步就得再上Canal，Canal伪装成MySQL的Slave去拉binlog，解析之后还要自己写消费逻辑推到目标库，链路长、开发量不小。

Dbsyncer的方案是把这两条路合并成一条。全量同步走批量读写，增量同步走binlog监听，两个能力都在同一个平台里配置和监控。对不做海量数据的团队来说，这个组合够用了。而且部署成本低，就一个Java进程，解压即用，不需要额外依赖消息队列、不需要写消费者代码。

选型这件事，关键看你手头的场景是什么。如果追求字节级吞吐，那DataX更合适；如果要做复杂的数据清洗流，Flink CDC这类流式计算框架可编程性更强。但如果你需要的只是一个“两边数据能保持同步”的通道，Dbsyncer的性价比确实高。

1.3 场景边界：它适合谁，不适合谁

实事求是地说，Dbsyncer适合数据量在千万行以下、同步时效性要求不苛刻的场景，比如测试环境同步、报表库同步、系统间数据初始化、读写分离的辅助副本。我在一个电商项目里，用它把线上订单库同步到报表库，每天自动化跑，稳定运行了几个月，没出过大问题。

如果数据量到了亿级，或者需要秒级甚至毫秒级的同步，那可能需要重新评估。Canal加自研消费端可以做更细的控制，Flink CDC可以做流式计算，这些方案复杂度更高，但同时上限也更高。Dbsyncer的并发调优和运维文档相对轻量，出问题时要靠日志来定位，团队里最好有人熟悉这套东西。

我的建议是：先别急着否定它，拿真实数据量做一轮压测，看同步延迟和资源占用是否满足预期，再决定要不要引入更重的方案。

2. 环境准备：从下载到控制台跑起来

2.1 JDK环境与安装包下载

Dbsyncer基于Java开发，机器上得有JDK。我这次用的是JDK 8，注意版本别太老也别太新，太老有些加密协议的兼容性跟不上，太新可能碰到依赖库的兼容问题。检查JDK版本：

java -version

如果还没装JDK，装OpenJDK 8或者Oracle JDK 8都行，配好JAVA_HOME。这里有个小提醒：Windows环境里PATH如果混了多个JDK版本，启动时可能出现版本不对的问题，最好统一一下。

安装包从GitHub或Gitee的releases页面下载最新稳定版，格式是zip压缩包。下载后解压到指定目录，我用的是/opt/dbsyncer。解压后能看到bin、lib、logs这些目录，整个安装过程没有需要交互的步骤，解压即完成安装。

2.2 启动与访问控制台

Linux下启动，我用的是nohup方式，这样断开SSH不会把进程带走：

cd /opt/dbsyncer nohup bin/start.sh > /var/log/dbsyncer.log 2>&1 &

启动后看日志，看到类似“Started Dbsyncer Application”的提示就表示成功了。默认端口是18686，浏览器访问http://服务器IP:18686就行。首次登录账号/密码是admin/admin，进去后强烈建议先改掉默认密码。

注意：如果部署在云服务器上，记得在安全组放行18686端口。我之前有一次在云上怎么都打不开界面，排查了半天才发现是安全组只开了业务端口，没放行这个管理端口，白白折腾了半小时。

Windows环境操作更简单，解压后直接双击bin/start.bat就能启动，命令行窗口保持住，日志会直接打印在里面。唯一要注意的是杀毒软件有时候会拦截Java进程的网络监听，遇到启动成功但访问不了的情况，先看看杀毒软件有没有放行。

2.3 控制台核心概念：连接器、映射、任务

Dbsyncer控制台里三个核心概念，刚接触容易混，先理清楚再配置：

• 连接器（Connector）：描述一个数据源端点，比如“源库-生产MySQL”、“目标库-报表MySQL”，保存连接信息。
• 映射（Mapping）：定义从源表到目标表的对应关系，包括字段映射、过滤条件。
• 任务（Task）：把映射挂到任务下，控制任务的启停和调度。

全量和增量配置，本质上都是在这三个概念的组合上做文章。想清楚自己是要“一次性把数据搬过去”还是“持续监听变更并同步”，后面操作起来方向就清晰了。

3. 数据库侧准备：账号权限与binlog配置

3.1 创建最小权限的同步账号

为了让Dbsyncer连接源库和目标库，建议单独建同步账号，别直接用root。源库账号既要读数据，又要拉binlog，所以SELECT和REPLICATION权限都得有：

CREATE USER 'dbsync_src'@'%' IDENTIFIED BY 'YourPwd123!'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dbsync_src'@'%'; FLUSH PRIVILEGES;

目标库只需要写入和基本的建表改表权限：

CREATE USER 'dbsync_dst'@'%' IDENTIFIED BY 'YourPwd123!'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX ON *.* TO 'dbsync_dst'@'%'; FLUSH PRIVILEGES;

权限这块按最小化原则给就好。有些朋友图省事直接给ALL PRIVILEGES，也不是不能用，但从安全角度讲风险大。万一同步账号被拖库，至少不能把整个实例的管理权限暴露出去。

3.2 binlog参数配置与验证

增量同步依赖binlog，而MySQL默认情况下binlog可能没开。租云数据库时尤其注意，有些默认配置是不开binlog的，要先确认。

编辑my.cnf或my.ini，在mysqld段下添加：

[mysqld] server-id = 223344 log-bin = mysql-bin binlog_format = ROW binlog_row_image = FULL expire_logs_days = 7 max_binlog_size = 256M

几个参数的作用逐个说一下：

• server-id：必须设置，同一个复制拓扑里每个节点要唯一。我碰到过两个实例配了相同server-id的情况，日志解析错乱得莫名其妙，换成不同ID就好了。
• binlog_format = ROW：增量同步需要行级日志，记录每行变更的前后镜像。只有这样才能精确解析出“哪一行变成了什么”，然后在目标库回放。
• binlog_row_image = FULL：日志里保留完整行数据。不设的话，某些场景下字段值可能不完整，解析出来的数据质量会打折扣。
• expire_logs_days：保留天数别设太短。增量任务如果宕机时间较长，断点之前的binlog已经不在了，续传就断了。
• max_binlog_size：控制单个binlog文件大小，不是必须项，但建议设一个合理值，方便管理和排查。

修改配置后重启MySQL：

systemctl restart mysqld

验证配置是否生效：

SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format';

log_bin为ON、binlog_format为ROW就达标了。另外SHOW MASTER STATUS;可以查到当前正在写的binlog文件名和位置，后面配增量同步的起始断点时用得上。

4. 全量同步实操：从连接器到任务跑通

4.1 创建源库和目标库连接器

登录控制台以后，先进“连接器管理”页面，点击新增连接器。选择MySQL，然后填连接参数：

• 连接器名称：方便识别，比如“源库-生产MySQL”
• IP地址、端口：数据库地址，默认3306
• 数据库名：要同步的库名
• 用户名、密码：刚才创建的同步账号

填完点“测试连接”，提示成功后再保存。源库、目标库各建一个连接器。

这里有个小细节：如果源库和目标库在同一台机器上，连接器里填的地址和端口一定要仔细区分。我试过一次把两个连接器填反了，结果全量同步跑完数据完全对不上，后来逐个排查才发现是连接器配错了。先测通再保存，能省很多后面的麻烦。

另外建议连接器命名带角色前缀。比如“源库-生产MySQL-订单库”、“目标库-报表MySQL-订单库”，后期连接器多起来以后，在同步映射页选择连接器时一眼就能认出来，不容易选错。

4.2 配置同步映射

进入“同步映射”页面，新建映射：

1. 选择源连接器和目标连接器，确认同步方向。
2. 选择要同步的表。Dbsyncer支持多张表一起选，如果你对表结构没有特殊要求，可以勾选自动建目标表。
3. 配置字段映射关系。源表的字段名一般和目标表一致，但有时也会遇到字段名不同或者目标表多了个字段的情况，这里可以手动调整。

映射保存后，全量同步的核心配置就完成大半了。整个过程里我建议先把映射关系检查一遍再启动任务，特别是源目标字段数量不一致时，宁可先调整也不要硬跑。自动建表这个功能对新手很友好，它能直接按照源表结构把目标表建出来，省掉手工比对表结构的时间。

4.3 运行全量同步并核对数据

进“任务管理”或“服务管理”，新建任务，把刚才的映射添加进去，启动任务。首次启动默认执行全量同步，界面上能看到同步状态和进度。

全量同步的实质就是把源表数据分批读出来，写入目标表。数据量大的时候耗时比较长，日志里会有同步过程的记录，留意有没有异常报错。跑完后去目标库核对数据量：

SELECT COUNT(*) FROM 目标表; SELECT COUNT(*) FROM 源表;

两边行数一致，全量链路基本就通了。再随机抽几条记录比一下字段值，重点看看时间字段和字符串字段，防止有早期排查不出来的隐藏问题。

4.4 全量同步的注意事项

全量同步最大的坑在超大表上。我之前同步过一张几百万行的订单表，默认配置下跑了挺久，中间日志还报过连接超时。后来把同步批次调小，延长了连接超时时间，才顺利跑完。几十万行以内的小表，用默认参数基本没问题。

另一个坑是源表和目标表结构不一致。目标表如果已经存在，但字段类型或索引不一样，同步可能在中途报错。我的建议是：没有特殊需求就让Dbsyncer自动建表，结构对齐问题能少一大堆。如果必须用已有表，提前把两边结构比对清楚再跑。

5. 增量同步实操：基于binlog的实时链路

5.1 增量同步原理：Dbsyncer如何感知数据变更

增量同步的技术核心还是binlog。Dbsyncer的增量同步器会伪装成MySQL的Slave节点，向源库请求binlog事件流。MySQL把增量变更记录推给它，它解析出插入、更新、删除操作和具体行数据，然后在目标库执行对应SQL，把变更重放出来。

这个原理理解透了，前面为什么要求binlog_format = ROW就顺理成章了。只有行级日志才能完整记录每行数据变更前后的值，解析出来才能做精确回放。如果是STATEMENT格式，记录的只是SQL文本，回放时变量上下文可能不一致，出现同步结果偏差就只能干瞪眼。

5.2 增量同步配置步骤与验证

增量同步的配置入口还是在同步映射里。大致步骤：

1. 在映射里把对应表的同步方式切到“增量启动”（不同版本按钮名称可能略有差异，但逻辑都是开启增量监听）。
2. 指定binlog起始位置。如果从零开始，可以先在源库执行SHOW MASTER STATUS;查出当前binlog文件名和Position，填进去。
3. 配置目标库连接和写入行为，比如批量写入的批次大小、事务控制方式。
4. 保存，启动任务。

启动后去源库做一条插入测试：

INSERT INTO 源表(id, name) VALUES (10001, 'test_sync');

然后去目标库查：

SELECT * FROM 目标表 WHERE id = 10001;

能看到这条数据，增量链路就通了。再试试UPDATE和DELETE，更新的行、删除的行在目标库也会同步变化，这才算完整验证过。

不同版本的控制台界面细节有差异。如果你在映射配置页没找到“增量”相关选项，先在任务维度的启动参数里找，有些版本是把启动模式放在任务启动时选择的。实在找不到就查一下对应版本的官方截图，按版本号对照着看，别拿旧版教程硬套新版界面。

5.3 断点续传与数据一致性

Dbsyncer在运行增量任务时，会把消费到的binlog位点持久化保存。进程重启后，它从上次记录的位点继续拉取，既不会重复消费也不会丢数据，这就是断点续传能力。

但这里有个隐藏风险：如果binlog保留时间过短，比如只保留了一天，而增量任务因为故障停了三天，重启后Dbsyncer发现需要的binlog已经被清理，就可能无法续传。所以生产环境里binlog的保留周期要结合同步任务的恢复时间来设计，不能拍脑袋设一个很小的值。

增量同步做的是真正意义上的“数据一致”，不只是插入，更新和删除也会逐一重放。如果你只想同步部分表，或者想过滤掉某种变更类型，映射里也有条件配置可以做。不过过滤逻辑本身要谨慎使用，过滤太激进可能漏数据，我一般能不用就不用。

5.4 增量同步的三大坑：时区、字符集与主键

先说时区。源库和目标库的time_zone如果不一致，同步过去的时间字段可能差几个小时。我在多时区部署的场景里踩过这个坑，后来在两个连接器的连接参数里明确了serverTimezone，时间字段才对齐。

再说字符集。源库是utf8mb4，目标库是latin1，中文同步过去直接变乱码。确保两端字符集一致，或者在连接串上指定characterEncoding=utf8，这两个动作至少做一项。

最后是主键。增量同步要定位变更的记录，天然依赖主键或唯一键。如果表没有主键，更新和删除操作的回放就容易出问题。我做完表结构检查后，发现没有主键的表都会先补一个主键再纳入同步范围，宁可稍微麻烦一点，也别等出问题了再回头补。

6. 常见问题与排查技巧实录

6.1 排查问题前的基本流程

遇到同步异常，别急着改配置，先按流程定位：

1. 看Dbsyncer日志，日志里会有异常堆栈，比界面提示具体得多。
2. 看控制台任务状态。有没有失败记录、同步日志里最后的成功位置在哪。
3. 验证源库和目标库连通性，用客户端手动连一下，确认账号权限、网络都正常。
4. 回头检查binlog配置和连接器参数，很多时候问题出在这两层。

日志里的关键词很有价值。比如看到“Access denied for user”，说明账号权限有问题；看到“Could not find first log file name”，多半是binlog文件不存在或位置过期。定位到关键词后，基本就能判断方向了。

6.2 常见问题速查表

这张表基本覆盖了我实际运行中遇到的大部分问题。如果你碰到的不在上面的列表里，先看日志关键词，再去对应模块排查，思路是一样的。

6.3 几个没有写进文档里的避坑心得

• 第一次跑全量同步前，先备份目标库相关表，防止同步异常把已有数据覆盖掉。
• 增量任务在运行中，尽量别去改映射配置。真需要改就先暂停任务，改完再启动，否则状态可能对不上。
• 目标库如果并发写入压力大，批次写入大小可以调小，避免大事务把线上的写请求拖住。
• 生产环境部署Dbsyncer，建议单独放一台机器，别和数据库实例挤在一起。Dbsyncer本身不算吃资源，但和数据库争CPU、内存会影响两边。
• 同步任务加个进程守护，比如systemd或supervisor，Java进程万一挂了能自动拉起来，比手动发现再处理强。

这些心得是我在多个项目里实际总结出来的，很多人盯着功能用，忽略了运维细节，于是功能越好用的工具越容易被“用坏”。

我个人实际操作下来的体会是，Dbsyncer这类开源带界面的数据同步中间件，最大价值不是替代DataX或Canal，而是把数据同步这件事的门槛降了下来。以前要写代码、搭框架才能做的事，现在填个表单就能看到数据在两端跑通，这种“所见即所得”对快速验证业务设想特别有用。当然它也有自己的边界，海量数据、复杂转换、低延迟场景还是得认真评估更专业的方案。如果你正在为一批MySQL数据找同步方案，不妨先按这篇文章的路径把环境搭起来，亲手感受一下全量和增量同步的实际效果，再决定要不要把它纳入你的技术栈。