Dbsyncer数据同步实战：MySQL增量与全量配置从入门到避坑

“Dbsyncer、数据同步中间件、MySQL、增量、全量配置”——这几个词摆在一起，基本就说明你已经遇到了那种“库里数据要搬家，又不能停机太久”的活。我一开始是自己写脚本同步的，后来发现同步脚本越写越多，补数、断点、重复记录全靠人肉盯，实在费劲。直到同事给我安利了 Dbsyncer 这个开源数据同步中间件，我用它在测试环境把一套 MySQL 的数据同步到另一套 MySQL，全量、增量都跑了一遍，今天就把整个实操过程记下来，给自己留档，也给第一次接触 Dbsyncer 的人省点弯路的功夫。

这篇文章不是官方文档那种点按钮式教学，而是我实际配了一套 MySQL 到 MySQL 的同步之后，把“为什么这样做”“配置的时候注意什么”“我踩过什么坑”都揉进去的完整记录。你如果是搬库、做读写分离、搭测试环境数据、或者想把一个库的改动实时同步到另一个库，这篇文章基本够用。

1. 为什么要用 Dbsyncer 做 MySQL 同步，而不是继续写脚本

1.1 先想清楚你说的是“全量”还是“增量”

很多新人在刚开始接触数据同步时，会把全量同步和增量同步混为一谈。全量的意思很直白：把源库某张表的数据一次性全部搬到目标库。说白了这就是一次批量数据搬运，数据量大不大只影响执行时间。但现实业务几乎都有“搬完还要继续跟着源库变”的需求，目标库要能实时或准实时追平源库产生的新增、修改和删除操作，这就得靠增量同步来实现。

我在最初写同步脚本的时候，全都是用“定时任务 + where 时间字段”实现的。这种方案短时间能跑，但坑特别多：源表没有 update_time 怎么办？物理删除的字段怎么同步？漏了一小时任务导致重跑又怎么去重？每个问题最后都是靠人肉补救，根本谈不上可靠。

Dbsyncer 这种中间件走了另一条路：它把“采集数据库变更日志”和“按规则回放变更”这两件事单独接住了。全量任务负责搬存量数据，增量任务盯着源库的 binlog 一类日志流，把数据库自身的变更还原成可执行的操作，再同步到目标库。你不再需要关心“这分钟源库多了几条、少了哪条”，因为日志已经把变化顺序写清楚了。

1.2 有 Canal 有脚本方案，为什么我选了 Dbsyncer

数据库同步领域确实不是没有别的选择，比如 Canal 也是非常知名的一套东西，我也用过。但 Canal 的问题是，它本质上是给你一个数据通道，消费者逻辑你还是得自己写代码，同时还要处理消息顺序、断点续传、连不上消息服务、部署一堆组件等问题。对于“我只是要把 MySQL A 同步到 MySQL B”这种需求，Canal 的整套链路又重又长。

Dbsyncer 最大的体验差异是“配置化”：界面上先把数据源配置好，再配置同步方向、同步表、字段映射，点一下就能看到任务状态和日志。它把很多同步中间件需要自己开发的环节做成了图形界面操作，对只想快速解决数据复制问题的人来说，门槛低太多了。而且它是插件化架构，当前的场景里我用 MySQL 做源端和目标端，只要关注 MySQL 对应的驱动和日志解析逻辑就行，以后要接别的数据库也不至于推倒重来。

我还想强调一点：不要把 Dbsyncer 理解成只能同步 MySQL。它可以接多种关系库和数据存储，只是我这篇只拆解 MySQL 到 MySQL 的路径。这是目前被问得最多、也是最容易上手验证的一种组合，把这条路跑通了，其它组合的界面操作逻辑基本是类似的。

1.3 出发前先对着清单检查一遍

Dbsyncer 在执行同步任务时，需要源库和目标库都能被正常访问，增量场景还要求源库开启日志记录。我第一次配的时候就因为漏了源库的 binlog 检查，导致增量任务一直卡在初始化阶段。建议你按这个前置条件先自查：

• 源端 MySQL 和目标端 MySQL 必须允许 Dbsyncer 所在主机远程连接，不能用 localhost 限制账号。
• 源端 MySQL 需要打开 binlog，并且日志格式建议是 ROW；具体检查方法下文会有 SQL。
• 目标端 MySQL 需要有与源端表结构对应的库表，最好连表结构一起准备好，字段类型尽量一致。
• Kafka、Redis 这类组件不需要，Dbsyncer 是直接通过数据库协议读取日志和写入数据，这一点比很多需要额外消息队列的方案简单。

我第一次在同事的机器上看到这套东西时，第一反应是“又要部署什么中间件服务”，实际上它就是一个可执行的 Java 服务包，启动完自带管理页面，界面操作占大头，完全不是那种要写一堆 YAML 的服务。

2. 环境准备和 Dbsyncer 启动

2.1 安装、启动 Dbsyncer 的整个流程

Dbsyncer 是个 Java 服务，所以机器上得有 JRE 或 JDK。版本这块不同版本要求不同，我当时用的环境是 JDK 8 以上的版本，建议你装 JDK 8 或 11，遇到问题少很多。Windows 上解压安装包后，找启动脚本直接点；Linux 上一般就是解压 tar 包，然后用 nohup 或 systemd 把启动脚本挂后台。

我当时的操作大概是这样的：

1. 从官方仓库的 Releases 页面下载对应系统的安装包。
2. 解压到指定目录，比如 /opt/dbsyncer。
3. 看目录下的启动脚本，Windows 是 .bat，Linux 是 .sh，给脚本加执行权限后启动。
4. 启动成功后，默认会监听一个 HTTP 端口，打开浏览器访问管理页面。
5. 第一次进入页面会要求初始化管理员账号，设置完就可以登录。

有一点你可能要注意：如果你把服务部署在云服务器上，一定要记得在安全组或者防火墙里放行 Dbsyncer 的访问端口，不然页面打开看不到。当然，为了安全，生产环境建议用 Nginx 反代加访问控制，别把管理端口裸奔到公网。

启动完成后，我们先不要急着建同步任务。我习惯先做一些基础配置检查和连通性验证，把问题前置，比到时候任务跑到一半报错再排查效率高得多。

2.2 源端 MySQL 的 binlog 相关配置检查

增量同步能不能成，关键在于源库有没有把每一次行变更记录在案。MySQL 里承担这个角色的是 binlog，也就是二进制日志，它在主从复制环境里是标配，但在很多单机业务库里可能是关着的。

你可以登录源库执行这条命令确认：

sql复制show variables like 'log_bin';
show variables like 'binlog_format';
show variables like 'server_id';

如果 log_bin 的值是 OFF，那说明当前实例没开 binlog。需要修改 MySQL 配置文件，常见配置项在 Linux 的 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 里：

ini复制[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
binlog_row_image=FULL
expire_logs_days=7
max_binlog_size=256M

这里几个配置都要理解一下：server-id 是实例的唯一编号，不能和同步链路中的其它实例重复，尤其你不能让源库和目标库都用默认的 1，否则日志拉取时身份会冲突；binlog_format=ROW 是我特别建议的形式，因为行级别的日志会记录每一行变更前后的内容，同步中间件解析起来不容易丢字段；expire_logs_days 控制日志保留天数，太短会导致同步任务中途断了日志被清理，太长会占磁盘。这些都改完后，需要重启 MySQL 实例才能生效。

配置完先别急，确认一下当前日志位点也有利于诊断：

sql复制show master status;

这条命令会返回当前正在写的 binlog 文件名和 Position。如果你只是想看到变化，可以先记录这个位点，后面增量任务从这附近开始接，就能少丢数据。我一般称这个位点为“断点坐标”，它几乎是增量同步里最重要的概念。

2.3 创建专门供 Dbsyncer 使用的数据库账号

我不太建议直接用业务库的 root 账号去配 Dbsyncer，因为同步服务要长期驻留，权限给太大有安全风险。建议单独建一个账号，权限只给够用的。Dbsyncer 读取 binlog 时，并不是靠物理文件直接读，是通过 MySQL 的主从复制协议去拉取，所以账号必须具备相应的复制权限。

参考 SQL 如下：

sql复制CREATE USER 'dbsyncer'@'%' IDENTIFIED BY '你的密码';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dbsyncer'@'%';
FLUSH PRIVILEGES;

如果是目标端数据库，需要给账号分配目标库的写权限，比如：

sql复制GRANT SELECT, INSERT, UPDATE, DELETE ON 目标库.* TO 'dbsyncer'@'%';
FLUSH PRIVILEGES;

实际测试时，如果你的同步任务要读源库表结构做映射，SELECT 权限必须保留。不要只给复制权限而忘了 SELECT，否则创建同步任务枚举表名时会查不到数据。

2.4 在管理页面里配置连接并验证连通性

启动好服务、检查好 binlog 后，接下来把 Dbsyncer 里的“连接”建好。这一步其实就是填数据库连接信息：连接名称、数据库类型、IP、端口、数据库名、账号、密码。

界面字段不多，但有两个细节很容易被忽略：一是连接串参数里的 serverTimezone，如果你所在时区不是 MySQL 默认时区，日期时间字段读取后可能出现偏差，我习惯显式设置成 Asia/Shanghai；二是驱动版本，Dbsyncer 一般会带常用驱动，但如果你连的是 MySQL 8.0，要注意驱动类型选对，有些老驱动连接 MySQL 8.0 时认证方式会产生兼容问题。

配完连接后，页面一般会提供测试按钮。点测试之前，先在命令行里用 mysql 客户端自己连一遍，确认网络通、账号通、能访问到具体库：

bash复制mysql -h 源端IP -P 3306 -u dbsyncer -p

很多“测试失败”的问题其实不是 Dbsyncer 的问题，而是源端 MySQL 的账号 host 限制、云安全组、防火墙或者端口根本没监听。先在命令行验证一次，能省掉很多界面报错带来的焦虑。

3. 全量同步的配置实操

3.1 全量同步适合什么阶段用

全量同步一般用在两个场景：一是你从零搭建一套同步链路，需要先把历史存量数据一次性导入目标库，为后面的增量同步打底；二是某些不需要持续更新的报表库、备份库，只做周期性的全量覆盖即可。

我在练手的时候，最喜欢用全量同步来验证整体配置链路，因为它执行逻辑直观：Dbsyncer 读取源表数据，经过映射，把数据写入目标表。如果全量跑成功了，至少证明网络、账号、表结构、映射这几大块没有问题，再去做增量同步就更有底气。

生产环境做全量同步时有一个常见的业务需求：业务不能停写。如果源表是持续有写入的在线表，全量同步期间源库还在不断产生新数据，同步完成之后如果你直接接增量，接缝处的数据很容易出现重复或丢失。所以我的经验是：能接受短暂停写的话，最好在业务低峰期暂停写操作，跑完一遍全量，再开增量；不能停写的话，就要记录任务开始时的 binlog 位点，在大体完成全量后，从那个位点回放增量，这个过程通常要专门设计“先全量后追日志”的执行策略，不能拿默认配置一把梭。

3.2 新建同步任务、配置表映射的具体操作

Dbsyncer 的逻辑是把多个环节拆成可复用对象：连接是连接，同步任务是同步任务。你之前配置的连接这时就能派上用场。新建同步任务时，界面上会要求选择驱动类型、源端连接、目标端连接和同步方向。

一般步骤大致是：

1. 进入同步任务管理，新建一个任务。
2. 给任务起名，比如 mysql_to_mysql_full，方便后面区分。
3. 选择驱动模式为全量同步，部分版本叫“全量同步”或类似名称。
4. 选择源端连接，点击后可以选择要同步的库表。
5. 选择目标端连接，确认目标库中对应的表。
6. 进入字段映射页面，检查源字段和目标字段是否一一对应上。

字段映射这步最容易出问题。如果你源表和目标表字段名一致，Dbsyncer 一般可以自动映射；如果两边字段名不同，需要手动把源字段拖到目标字段上。主键字段务必确认好，Dbsyncer 很依赖主键来判断数据在目标端是否已存在，以此决定做插入还是更新。如果源表没有主键，全量同步时遇到重复数据只靠普通规则很容易撞车，我建议源表尽量选有主键或者至少逻辑唯一键的表来同步。

如果表特别大，一个全量任务几百 GB 也是常见的。这时不要以为点一个同步就能万事大吉，先做一两个小表验证，或者用查询条件限制部分数据同步。Dbsyncer 的驱动里通常可以设置查询过滤条件，你可以试着先同步昨天的数据，甚至可以加 where id < 1000 做小范围测试。

3.3 同步前对表结构和目标库的处理细节

我在做 MySQL 到 MySQL 全量同步之前，会习惯性地先做几件事：

确认目标表已存在。部分驱动支持自动建表，但如果你用的是已有环境，我更建议你直接根据源表建表语句在目标端手工建好。比如先导出源表结构到目标库执行：

bash复制mysqldump -h 源端IP -u dbsyncer -p --no-data 源库 表名 | mysql -h 目标端IP -u 目标账号 -p 目标库

这样导入就是完全一致的物理表结构，比自动建表更容易预测。

如果目标表已经存在，但里面有残留数据，你要根据业务决定是先清空还是继续追加。全量同步如果你希望目标表和源表完全一致，通常需要先清空目标表，不然源表删过的记录在目标表里可能残留。如果目标表里没有数据，那就不存在这个问题。

同步过程中不要让应用同时写目标表。虽然 Dbsyncer 写入时会有批量提交，但目标端如果也有应用在写同一张表，两边并发操作会造成数据错乱。我最开始练手时，直接在两边手动插入了几条测试数据，结果全量同步结束后，目标表里混着一堆中间状态数据，排查半天才反应过来是自己手欠。

3.4 执行任务和验证数据一致性的几个土办法

全量任务启动之后，先看任务状态和日志。如果日志出现 SQL 执行异常、字段类型转换错误，大多能在日志里看清楚是哪一行哪一列出了问题。不用急着改任务参数，先把表结构和数据样本拉出来对比，往往就是类型不一致导致的。

确认任务成功完成后，可以用简单的 count 验证两边行数：

sql复制select count(*) from 源库.表名;
select count(*) from 目标库.表名;

这里有个小坑：仅仅是 count 对不上，可能不只是漏同步，还有可能是源表和目标表结构差异导致有些行写入失败。我习惯再用一个抽样对比 SQL 来核对另一组关键字段，比如 select 出源表和目标表主键字段的集合，用 not in 或 not exists 找差异。如果差异行很多，直接去翻 Dbsyncer 执行日志更快，因为它是按批提交的，日志会记录每条失败 SQL 和原因。

我当时第一次全量同步，源表用了一个 VARCHAR 主键，目标表结构当时误建成 INT，结果同步任务在日志里反复报主键转换失败，底下一大堆“Data truncation”的错误。后来把表结构统一成 VARCHAR 才顺利跑完。所以说别小看 DDL 的一致性检查，同步工具只能按你给的结构写数据，类型差异导致的问题它不会替你骂自己。

4. 增量同步的配置实操

4.1 增量同步背后的“日志回放”原理

全量同步跑通之后，进入重头戏：增量同步。增量同步之所以能做到不依赖业务代码，是因为 Dbsyncer 借助了 MySQL 自身的复制机制。你可以把它理解成一个做了伪装的“从库”，它连接源库后按日志位点拉取 binlog，解析出哪些表发生了什么操作，然后把变更翻译成 INSERT、UPDATE、DELETE 等操作回放到目标库。

这个过程里，最重要的一条规则是：目标库看到的结果，应该是源库经过一系列操作后的最终一致结果。源库执行一条 UPDATE 把 A 改成 B，中间不管经过多少步骤，Dbsyncer 最终也应该把 A 改成 B，而不是只同步新增的数据，或只同步变化的那一部分字段。第 2 节我为什么坚持让你把 binlog_format 设成 ROW？因为 ROW 格式记录的是行快照，解析出的结果最贴近实际数据；如果是 STATEMENT 格式记录的是 SQL，某些函数或不确定性语句解析出来容易导致两边数据不一致。

Dbsyncer 会保存自己当前消费到哪个日志位点。这样即使中间件重启，它也能从上次断掉的位置接着同步。你在界面上看到的增量任务状态，本质就是那套断点位点的可视化呈现。遇到差数据不要立刻怀疑中间件丢数据，先查这个同步任务当前日志位点比源库的最新位置落后多少，往往是定位问题的第一步。

4.2 全量任务之后如何平滑切到增量

我推荐的标准操作顺序是：

1. 在业务低峰期选择一个时间点，记录源库当前的 show master status 位置。
2. 在这个时间点前后执行全量同步，把存量数据搬过去。
3. 全量同步成功后，新建一个增量同步任务。
4. 增量任务启动时，把日志位点设置为刚记录的位置，或从任务创建时自动定位到当前最新位点。
5. 观察增量任务日志，确认它已经进入正常监听状态。
6. 手动在源库插一条测试数据，看目标库是否在几秒内出现。

这套顺序最怕的是漏看第三步和第四步的衔接。如果你在全量同步过程中业务一直在写，全量结束之后增量任务却从“当前最新位点”开始接管，那全量同步期间产生的变更就全部丢了。这不是中间件能力不行，而是操作时序设计的不对。所以在全量任务执行前先记录源库日志位点，然后把增量任务的起点定位到位点，这是生产环境同步的标准姿势。

如果你的 Dbsyncer 版本在图形界面里没有直接暴露“起始日志位点”输入框，可以从任务日志里看它当前使用的是什么策略。我在测试中发现，不同版本默认行为会不同，有的默认从当前最新位点开始，有的会提供位点回填。不要在没验证的情况下直接跑生产。稳妥起见，启动增量前先手动做一条 INSERT，验证增量通道确实通了，再大规模放业务。

4.3 增量任务里的几个可选配置项怎么调

先说明一点，不同版本可配置项的名称会有差异，核心概念是通用的。

• 监听表设置：如果你只想同步某几张表，名字一般要写清楚，否则中间件默认会监听连接上整个库的变更。
• 写入线程数与批量大小：默认值通常可以跑，小规格机器上不要一味加线程，数据库连接数是瓶颈，不是同步越快越好。
• 忽略操作类型：有些场景你不想同步 DELETE，怕误删目标库，Dbsyncer 一般可以在驱动里选择关注哪些操作类型。
• 异常处理策略：跑到某条数据报错时，是继续跑后面的，还是停下来。我个人建议前期调试时让它停下来，方便定位，稳定后再改成继续跑并记录日志。

这些配置没有一个绝对答案，但你可以按这个思路去试：先带默认参数跑一个小表，通过拉大并发量看目标库的写入延迟，如果目标库的 CPU 和磁盘没有明显压力，就不需要动。

4.4 用一条测试 SQL 验证增量通道

配置完毕，别急着把整个业务流量切过去，先用最简单的操作验证。

在源库执行：

sql复制insert into 同步表名 (id, name, update_time) values (10001, 'test-dbsyncer', now());

然后等两秒，查目标库：

sql复制select * from 同步表名 where id = 10001;

如果能查到，说明新数据插入通道没问题。再执行一次 UPDATE：

sql复制update 同步表名 set name = 'test-dbsyncer-updated' where id = 10001;

等两秒再去目标库查字段有没有变化。最后试一下 DELETE：

sql复制delete from 同步表名 where id = 10001;

等两秒再查目标库，该记录应该消失，或者根据你配置的忽略操作类型决定是否保留。这种“插改删”三轮小实验虽然土，却能一次性把增量链路的三个动作都验证掉。如果插能同步、改不能同步，大概率是 UPDATE 触发时日志解析或主键映射出了问题，比上线后才发现要舒服太多。

我那时就做过一次马虎事：源表有多个唯一索引，我在测试环境把目标表也建了一模一样的唯一索引，结果全量导入时没冲突，增量跑的时候两条记录因为另一个唯一键撞了，导致任务一直报 duplicate entry。后来简化目标表索引，只保留主键，才把测试跑顺。

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

5.1 源库日志没开启或状态异常

如果增量任务一直提示连接日志失败，或任务日志里找不到可供解析的 binlog 文件，最常见的两个原因是：

一是源库 log_bin 没有打开，或打开后没有重启实例。这种问题用 show variables like 'log_bin' 一眼就能确认。

二是 binlog 文件被清理过或日志过期时间太短，中间件想从配置的旧位点拉日志，但源库已经没有那个文件了。遇到这个问题，要么把日志过期时间调长，要么放弃旧位点，重建增量任务并把位点放到当前最新位置。生产环境要保持断点能力，日志保留时间必须长于你的同步链路可能中断的最长时间。

5.2 MySQL 8 驱动或认证方式导致的连接失败

MySQL 8 默认的认证插件是 caching_sha2_password，老的 JDBC 驱动不一定支持。连接 Dbsyncer 数据源失败时，把日志拉到最底部，如果看到类似 “Public Key Retrieval is not allowed” 或 “Unable to load authentication plugin” 的报错，基本就是驱动版本或连接参数的问题。

解决办法一般有两种：一是换用较新的 MySQL 驱动，并让 Dbsyncer 使用新驱动类型；二是如果测试环境图省事，把账号的认证插件改成 mysql_native_password：

sql复制ALTER USER 'dbsyncer'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

线上环境建议优先更换驱动参数，不建议长期使用旧认证方式。

5.3 时区、日期与字段类型不一致导致的数据错乱

MySQL 连接串里的 serverTimezone 参数虽然看起来不起眼，但日期类型多的时候出问题非常诡异。比如源库存的是 UTC 时间，Dbsyncer 默认用 JVM 时区解析，写进目标库后你会发现时间整体偏了 8 个小时。

排查这类问题时，先用最简单的方式确认两边的原始值：分别从源库和目标库执行 select now()，看基础时间是否一致。再去检查连接串的时区参数和服务端时区设置。目标库的字段类型也要尽量和源库一致，如果源表的 DATETIME 到目标表变成 VARCHAR，字符串格式化极容易埋雷。

5.4 主键、唯一索引对同步任务的深层影响

我在这篇里反复强调主键，是因为 Dbsyncer 判断增量操作落到目标库时是插入还是更新，主键起着绝对性作用。如果目标表主键和源表主键定义不一致，增量解析出来的主键值可能定位不到目标表中的正确行，导致同样的数据插入多次，或者 update 影响不到行。

常见问题还有目标表有额外的唯一索引。源表本来只是主键冲突少，但目标表因为业务需要额外加了一个唯一索引，结果源库对普通字段的更新在目标库也触发唯一键冲突。同步链路的目标表既然是同步用的，我建议尽量让表和源表结构保持一致，尤其是约束和索引不要自作聪明地多添加。

5.5 常见问题速查表

注意：如果 Dbsyncer 的 UI 版本存在差异，某些按钮位置和字段名称可能和你在界面上看到的不完全一致，但“连接—同步任务—驱动映射—日志状态”这条链路是固定的。你只需要抓住真正起作用的概念，界面细节翻官方文档或者直接读执行日志都能跟上。

最后再分享一个我觉得很受用的小习惯：练手阶段不要一开始就配置正式库之间的同步。先把 Dbsyncer、源库、目标库都跑在本地或隔离的测试环境里，用两个小库、几张几百行的表，按照“全量搬运—插改删测试—重启中间件—断点续传”的顺序完整过一遍，把基本的手感和界面逻辑练顺。我那次从装好到全量增量都跑通，总共花了一个多小时，中间大部分时间不是在等数据同步，而是在一遍遍看日志和调连接串参数。这个中间件把核心的同步流程替你封装好了，真正考验人的还是提前设计好表结构、日志位点和权限，这些准备工作越扎实，后面越不容易出状况。