免费数据库同步工具实战指南：从DataX到Canal的选型与配置

1. 为什么免费数据库同步软件是个伪命题但又是个真需求先说结论免费的数据库同步工具不仅存在而且不少都是生产环境验证过的靠谱方案。但免费两个字背后藏着几个需要你先想清楚的问题——你要同步什么、同步多快、同步到哪、丢了数据能不能接受。这四个问题不搞清楚再好的工具到你手里也是定时炸弹。我见过太多人一上来就搜数据库同步软件然后随便找个工具装上配完之后发现要么同步延迟大得离谱要么同步到一半报错直接卡死更惨的是主库删了一条记录从库半小时后同步过去把另一条无辜数据也删了。这些坑不是工具不行而是选型阶段就错了。所以这篇文章不打算只给你列一串软件名单而是从实际场景出发拆解几条成熟的免费方案有纯开源工具有数据库自带的生态组件也有 NAS 上开箱即用的同步玩法。每个方案我都会讲清楚它适合什么场景、不适合什么场景、配置的时候哪里最容易翻车。先说一个很多人忽略的点数据库同步和数据库迁移是两件事。迁移是把数据从 A 搬到 B搬完就完事同步是A 和 B 长期保持状态一致。前者可以用一次性导出导入后者必须考虑增量、冲突、延迟、断点续传。你搜数据库同步软件的时候如果需求其实是一次性迁移那用同步工具反而会把自己绕晕。另外这个领域还有一个常见误区以为同步工具是装上就能用的傻瓜软件。实际上除了少数商业产品能做到接近零配置大多数免费工具都需要你具备一定的数据库基础——知道主键怎么设计、了解 binlog 是什么、能看懂基本的日志报错。这不是门槛而是所有生产级数据同步方案都绕不开的基本功。2. 先盘点目前主流的免费同步方案有哪几条路线市面上的免费方案看着多实际上路线很清晰主要分四类。我按上手难度从低到高、实时性从低到高的顺序来盘。2.1 数据库自带的同步机制最容易被忽略的免费很多人不知道主流数据库本身自带同步能力根本不需要额外装软件。MySQL主从复制Master-Slave Replication是官方内置功能binlog 日志驱动支持异步复制、半同步复制延迟通常能做到秒级以内。适用于 MySQL 实例之间的数据冗余、读写分离、跨机房灾备。PostgreSQL流复制Streaming Replication同样是内置能力物理复制和逻辑复制都有逻辑复制在 PostgreSQL 10 之后非常成熟可以做到指定表级别的同步。SQL ServerAlways On 可用性组是最正统的方案但配置复杂度高。更轻量的是复制功能Replication特别是事务复制Transactional Replication能把某几张表实时推送到订阅库很多用 SQL Server 的人一辈子没碰过这个功能其实它是被严重低估的同步利器。OracleData Guard 是标准答案但 Oracle 本身不免费这里不展开。这类方案的优势是零额外成本、稳定可靠、和数据库引擎深度集成劣势是同构限制——MySQL 只能同步到 MySQL跨数据库类型就要换路线了。2.2 开源同步中间件跨库同步的主力军如果需要在 MySQL 和 PostgreSQL 之间、或者 MySQL 和 Oracle 之间同步就需要中间件了。目前最主流的开源方案有三个DataX阿里巴巴开源的离线数据同步工具支持 MySQL、PostgreSQL、Oracle、SQL Server、HDFS、Hive、HBase、Elasticsearch、达梦、ClickHouse 等几十种数据源。最大特点是异构能力极强但不支持实时同步只能做定时批次同步。Canal也是阿里巴巴开源的基于 MySQL binlog 的增量订阅组件专门做 MySQL 到 MySQL / Kafka / Elasticsearch 等下游的实时增量同步。延迟一般在毫秒到秒级。DebeziumRed Hat 主导的开源 CDC 框架基于 Kafka Connect支持 MySQL、PostgreSQL、SQL Server、MongoDB 等主流数据库的实时变更捕获。相比 CanalDebezium 的社区更国际化、生态更完整但对基础设施要求更高——它依赖 Kafka。路线图大致是这样的要离线批量同步选 DataX要 MySQL 实时增量选 Canal要全数据库类型的实时 CDC 且不在乎引入 Kafka选 Debezium。2.3 图形化免费工具小团队和单机环境的救命稻草很多人其实只有一两台服务器数据量不大只是想让某个数据库的某个表定期同步到另一个地方搞 DataX 写脚本太重了这时候图形化工具反而更合适。DBeaver虽然是数据库客户端但它的数据迁移功能相当好用支持直接从 A 库选中表拖到 B 库适合一次性或低频手动同步。Navicat部分免费版本Navicat 有数据同步和数据传输模块界面操作非常友好。但要注意免费版功能受限且这是商业软件这里提它是因为确实有不少人在用免费的试用/精简版本。HeidiSQL开源免费支持 MySQL、PostgreSQL、SQL Server有简单的数据导出导入能力适合 Windows 环境。这类工具的特点是人肉同步——需要人工触发不适合 7x24 小时自动同步但胜在零配置成本特别适合马上要数据、不想折腾的环境。2.4 NAS 生态内置方案群晖用户的隐藏技能回到热搜词里的群晖 sql 数据库同步。群晖 NAS 作为中小团队和个人开发者很常见的存储设备除了当文件服务器还经常被用来跑数据库——比如 SQL Server、MariaDB、PostgreSQL 的 Docker 镜像都用群晖跑过。群晖本身没有一键同步数据库的套件历史上有过一些第三方套件但维护状况不稳定所以主流的做法是方案 A在群晖 Docker 里跑 Canal 或 DataX 容器实现数据库同步。这是最群晖范的做法充分利用了 Docker 能力。方案 B群晖的 Hyper Backup 配合数据库容器的定时 dump做伪同步——严格来说这是备份不是同步但很多人实际要的只是NAS 上有一份最新的数据这种情况备份就够用了。方案 C如果同步的源端或目标端本身就是群晖上的数据库容器那么直接用数据库原生复制机制两边都是容器也能复制。3. 按场景对号入座你的情况到底该选哪个走完工具盘点接下来是这篇文章我个人觉得价值最大的一段场景匹配。我梳理了五个最高频的需求场景每个场景都给出明确的工具选型和理由。3.1 场景一MySQL 主库挂了我要立刻切到备库这是最经典的高可用场景。要求同步延迟低、断点续传能力强、切换流程简单。推荐方案MySQL 原生主从复制半同步复制模式配合 MHA 或 Orchestrator 做自动故障转移。为什么不是 Canal/DataXCanal 只能做数据同步做不了主从切换时的日志位点管理和选举DataX 是离线的延迟分钟级起主库挂了备库可能还差好几批数据。配置要点简单提一嘴主库开启log-bin、设置server-id创建复制专用账号并授权REPLICATION SLAVE备库CHANGE MASTER TO填主库 binlog 文件名和位点然后START SLAVE。字不多但每个参数都有讲究特别是sync_binlog和innodb_flush_log_at_trx_commit这两个参数直接决定主库崩溃时会不会丢数据。3.2 场景二业务数据要实时同步到 Elasticsearch 做搜索非常多公司的业务库是 MySQL搜索用的是 Elasticsearch。要求同步延迟秒级以内且不能影响业务库性能。推荐方案Canal 监听 MySQL binlog投递到 Kafka再由 Kafka Consumer 写入 Elasticsearch。链路长但每一步都成熟可靠。为什么不用 Go-MySQL-Elasticsearch 之类的直连工具早期确实有人直接用 Canal 连 ES但后来发现一旦 ES 短暂不可用Canal 的消费位点管理会很别扭。中间加一层 Kafka相当于给同步链路装了个蓄水池数据库抖动、ES 重建索引都不怕消息积压了不会丢。注意如果数据量不大日均变更几万条以内确实可以直接用 Canal 的客户端 adapter 直连 ES省掉 Kafka。但如果日均变更量超过百万建议还是老老实实上 Kafka。这是我踩过坑后得出的结论。3.3 场景三定期把生产库的部分表同步到分析库典型需求运营要拉数据看报表但不想让他们直接查生产库或者每天晚上要把线上库同步到离线数仓。推荐方案DataX 定时增量同步。用 Shell 脚本或 Crontab 控制执行频率每次根据上次同步的最大主键或时间戳拉取增量数据。这个方案便宜、可控、对生产库压力小。配置一个 DataX 的 JSON 作业里面写清楚数据源、目标源、列映射、切分方式然后脚本里动态传入--where条件做增量我后面会专门演示这个配置。3.4 场景四本地 SQL Server 数据要同步到另一台服务器这里有两种情况如果你两边都是 SQL Server优先用 SQL Server 的事务复制Transaction Replication发布-订阅模式配置好后延迟秒级支持筛选指定表、指定行。如果目标端是 MySQL 或其他库那就用 DataXSQL Server 作为 Reader 数据源性能也够用。群晖用户特别留意很多人的 SQL Server 跑在群晖 Docker 里这时候事务复制的配置会更繁琐因为容器网络、主机名解析、SQL Agent 服务都要额外处理。我的建议是——如果两边都是群晖 Docker 里的 SQL Server直接对容器做端口映射然后按常规事务复制配置如果有一边不是 SQL Server那就用 DataX 容器定时跑。3.5 场景五多实例 MySQL 增量汇总到一个大实例热搜词里专门提到了datax 实现数据库多个实例的增量同步这是个非常典型的数据汇聚场景。比如公司有多个分部每个分部一套 MySQL总部要把所有分部的数据定期汇总到一个分析库。用 DataX 完全可以实现写多个 JSON 作业每个作业对应一个分部的数据库实例然后统一个 Shell 脚本逐批执行。要点有两个。第一每个分部必须有全局唯一的业务标识比如每张表都带branch_id字段否则数据汇聚后没法区分来源、主键还可能冲突。第二增量条件不能只依赖单表自增主键因为多个分部的自增主键会撞建议统一用update_time时间戳 branch_id做增量边界。4. 实操演示一用 DataX 实现 MySQL 多实例增量同步含完整配置DataX 是这几条路线里配置最典型、最值得花篇幅讲的。它能覆盖离线批量同步的大部分场景而且多个实例增量同步的需求在社区里问得最多。我以一个真实场景为例——假设有三台 MySQL 实例分别在不同地域需要每天凌晨 2 点增量同步到总部的分析库。4.1 环境准备与关键配置项首先到 DataX 的 GitHub Releases 页面下载对应版本的datax.tar.gz解压后目录结构如下datax/ ├── bin/ │ └── datax.py # 启动脚本 ├── conf/ │ └── core.json # 核心配置主要是 channel 并发数 ├── job/ │ └── *.json # 你的同步作业 ├── lib/ # 依赖的 jar 包 ├── plugin/ │ ├── reader/ # 各种数据源读取插件 │ └── writer/ # 各种数据源写入插件 └── tmp/部署完后做一个快速验证跑一下自带的示例作业python bin/datax.py job/job.json看到任务启动时刻和任务结束时刻以及bytes统计信息就说明安装成功。4.2 写一个支持增量条件的同步作业DataX 的作业是一个 JSON 文件核心三段job.setting速度控制、job.content读写配置、job.content[0].reader.parameter.connection连接信息。这里我直接给一个 MySQL 到 MySQL 的增量同步例子{ job: { setting: { speed: { channel: 4, byte: 1048576 } }, content: [ { reader: { name: mysqlreader, parameter: { username: sync_user, password: your_password, connection: [ { querySql: [ SELECT id, branch_id, user_name, order_amount, update_time FROM t_order WHERE update_time ${INC_START_TIME} ], jdbcUrl: [ jdbc:mysql://192.168.1.101:3306/order_db?useSSLfalsecharacterEncodingutf8 ] } ] } }, writer: { name: mysqlwriter, parameter: { username: sync_user, password: your_password, writeMode: insert, column: [id, branch_id, user_name, order_amount, update_time], session: [set session sql_modeANSI], preSql: [delete from t_order where branch_id ${branch_id} and update_time ${INC_START_TIME}], connection: [ { jdbcUrl: jdbc:mysql://192.168.1.200:3306/analysis_db?useSSLfalsecharacterEncodingutf8, table: [t_order] } ] } } } ] } }这个配置有几个关键点需要解释。第一个关键点是querySql里的${INC_START_TIME}变量。DataX 本身支持在 JSON 里写占位符运行时通过-p参数注入。用 Shell 脚本动态计算同步起始时间每次跑完后把时间更新到文件里下次跑就接着上次的走。第二个关键点是writer里的preSql和writeMode。因为增量同步不能简单insert否则重复跑会主键冲突或产生重复数据。我的做法是在写入前按branch_id和update_time删除目标库中同一批数据再执行 insert 插入。这本质上是先删后插的幂等策略保证任务重跑不会产生脏数据。如果你确定只需要追加不需要更新可以把preSql去掉writeMode改成insert如果要覆盖更新就改成replace。第三个关键点是channel并发数。speed.channel表示读取和写入的并发通道数4 是比较保守的值数据量大的机器可以调到 8 或 16。但如果目标库性能一般并发太高反而会把目标库拖垮。建议先用 4 跑一次看耗时再逐步调大不要一上来就 16。4.3 Shell 调度脚本多实例逐批同步的完整姿势单作业只能同步一个实例多实例增量同步需要一个调度脚本。下面是简化版脚本核心逻辑是遍历配置文件里的实例列表逐个执行同步任务并把每次的同步时间记录到日志里。#!/bin/bash # multi_instance_sync.sh DATAX_HOME/opt/datax JOB_DIR/opt/sync_jobs LOG_DIR/var/log/datax_sync DATE_STR$(date %Y-%m-%d %H:%M:%S) # 读取实例配置格式实例名,IP,端口,数据库名 INSTANCE_LIST( branch_a,192.168.1.101,3306,order_db branch_b,192.168.1.102,3306,order_db branch_c,192.168.1.103,3306,order_db ) for item in ${INSTANCE_LIST[]}; do IFS, read -r branch_name db_ip db_port db_name $item # 增量起始时间默认取当前时间前一小时 INC_START_TIME$(date -d 1 hour ago %Y-%m-%d %H:%M:%S) # 实际项目中应该从上一次同步记录文件读取 if [ -f ${LOG_DIR}/${branch_name}.last_time ]; then INC_START_TIME$(cat ${LOG_DIR}/${branch_name}.last_time) fi echo [${DATE_STR}] 开始同步 ${branch_name}增量起点: ${INC_START_TIME} python3 ${DATAX_HOME}/bin/datax.py \ -p -DINC_START_TIME${INC_START_TIME} -Dbranch_id${branch_name##*_} \ -l ${LOG_DIR}/${branch_name}.log \ ${JOB_DIR}/${branch_name}_sync.json if [ $? -eq 0 ]; then NEW_START_TIME$(date %Y-%m-%d %H:%M:%S) echo ${NEW_START_TIME} ${LOG_DIR}/${branch_name}.last_time echo [${DATE_STR}] ${branch_name} 同步完成 else echo [${DATE_STR}] ${branch_name} 同步失败跳过时间更新 ${LOG_DIR}/error.log fi done这个脚本设计上有几个值得说道的地方起始时间文件机制每次任务成功后把当前时间写入last_time文件。下次执行时从文件读取而不是简单粗暴地用当前时间减一小时避免漏数据。注意这里做了一点安全冗余——实际时间比update_time最大值再往前推 60 秒防止刚好在边界变更的数据被漏掉。失败不更新时间同步失败时不更新last_time下次执行还会从头拉配合目标端的幂等删除不会产生重复数据。每个实例独立日志多实例并行排障时各看各的日志不然三个任务打在一个日志文件里排查起来想哭。4.4 增量同步易踩的三个坑DataX 增量同步看起来简单实际跑起来容易踩下面几个坑都是真实案例。坑一时间字段的格式不一致。源库update_time如果是datetime目标库如果建的varchar或者源库是timestamp目标库是datetimeDataX 类型转换有时会静默丢精度。解决办法是在查询 SQL 里统一DATE_FORMAT(update_time, %Y-%m-%d %H:%i:%s)别指望 DataX 自动处理。坑二源库大表没走索引。WHERE update_time ...这条查询如果用不到索引每天同步就是一次全表扫描对源库压力巨大。所以源库的update_time字段一定要建索引否则数据量过了千万级别后同步任务会把源库 CPU 拉满。有个好习惯在 DataX 的querySql里先用EXPLAIN验证执行计划不要想当然。坑三目标库并发写入导致的死锁。多个 channel 同时写入同一张表在 InnoDB 下容易出现锁等待超时。DataX 报错信息通常类似Lock wait timeout exceeded; try restarting transaction。解决办法一是降低channel到 2 或 4二是调整 InnoDB 锁等待超时时间innodb_lock_wait_timeout适当调大比如 50 秒三是在写入前先按主键排序让并发写尽量不冲突。第三条更治本DataX 的querySql里可以加ORDER BY id。5. 实操演示二群晖 NAS 上配置 SQL Server 数据库同步的完整链路热搜词里专门有群晖sql数据库同步这块值得单独拿出来讲。群晖跑 SQL Server 的场景通常有两种一是公司用群晖当测试/开发数据库服务器需要和办公室电脑上的 SQL Server 保持同步二是生产库在云服务器群晖放一份做灾备。这两种情况配置思路完全不同我分别说。5.1 场景一群晖 Docker 跑 SQL Server和另一台 SQL Server 做事务复制前提条件群晖上已经用 Docker 装好了mcr.microsoft.com/mssql/server镜像并能正常连接。事务复制是 SQL Server 标准功能但容器里配置有几个特殊点。第一步确认 SQL Agent 已启动。SQL Server 镜像默认 SQL Agent 是停止的而事务复制依赖 Agent 作业。连接进容器执行docker exec -it mssql /opt/mssql/bin/mssql-conf set sqlagent.enabled true docker restart mssql第二步处理容器主机名问题。事务复制的发布服务器和订阅服务器之间通过主机名通信容器重建后主机名会变导致复制失效。解决办法是在容器启动时固定 hostnamedocker run -d --name mssql \ --hostname mssql-sync \ -e ACCEPT_EULAY \ -e SA_PASSWORDYourStrongPassword \ -p 1433:1433 \ -v /volume1/docker/mssql/data:/var/opt/mssql \ mcr.microsoft.com/mssql/server:2019-latest这样即使容器停了再启主机名也一直是mssql-sync不会变。第三步配置发布和订阅。在 SSMS 里右键复制-本地发布-新建发布选择要发布的数据库和表注意发布类型选事务发布快照代理和日志读取器代理都选在 SQL Agent 启动时自动运行。订阅端同样在复制里新建订阅选推送订阅这样发布服务器主动推数据订阅端不需要额外开端口。有一个容易忽略的细节事务复制要求发布表必须有主键否则报错表没有主键列。被这个坑过的人不在少数所以发布前一定要检查所有表的主键情况。5.2 场景二群晖作为从库通过定时任务从云数据库拉取数据如果源端在云上比如云数据库 MySQL群晖上跑的目标库是 Docker 里的 MariaDB 或 SQL Server这种跨环境场景更适合用 DataX 容器方案。群晖的 Docker 套件里直接搜索datax镜像或者用registry.cn-hangzhou.aliyuncs.com/xuwei/datax这类社区镜像拉下来后挂载一个job目录把 JSON 作业放进去。具体步骤在群晖 File Station 创建/docker/datax/job目录。把写好的 JSON 作业传到该目录。Docker 运行容器时挂载目录到容器内的/opt/datax/jobdocker run -d --name datax \ -v /volume1/docker/datax/job:/opt/datax/job \ -v /volume1/docker/datax/log:/opt/datax/log \ registry.cn-hangzhou.aliyuncs.com/xuwei/datax \ sleep infinity用群晖的任务计划设置一个定时任务到点执行docker exec datax python /opt/datax/bin/datax.py /opt/datax/job/sync_order.json群晖任务计划支持设置运行用户为 root执行上述命令即可。这套方案的优势是不用在群晖上额外安装 Python 环境DataX 跑在容器里和宿主机隔离依赖干净。5.3 群晖场景的高频翻车点翻车一卷挂载权限不对。DataX 容器要以非 root 用户跑但群晖 NAS 的目录权限默认可能不够导致容器写不了日志。解决办法是在 File Station 里把/volume1/docker/datax的权限给到Everyone可读写或者启动容器时加--user root参数测试环境图省事可以这样生产不建议。翻车二网络模式导致连接不上数据库。群晖 Docker 默认 bridge 网络容器访问宿主机上的数据库时要用host.docker.internal或宿主机局域网 IP不能写localhost。但host.docker.internal在群晖 Docker 的旧版本上不支持最稳妥的是写群晖的局域网 IP例如jdbc:mysql://192.168.1.200:3306/...。翻车三时间同步问题。群晖如果没有开启 NTP 时间同步容器内时间会漂移导致增量同步的起始时间不准。遇到那种同步过来总是差几条数据的诡异问题先检查时间这是优先级最高的排查项。6. 增量同步方案的进阶思路从能同步到不出事工具能跑通只是第一步生产环境里更重要的是可观测性和数据一致性校验。这两件事做不好同步任务跑了一年突然出问题你连从哪开始排查都不知道。6.1 用校验任务兜底增量同步最大的风险是漏数据——binlog 清理、源库宕机、任务失败没及时发现都可能导致目标库和源库慢慢不一致。等你发现的时候可能已经差了几十万条数据。我常用的办法是每天跑完增量同步后做一个全表 count 和 sum 校验。-- 源库 SELECT COUNT(*), IFNULL(SUM(order_amount), 0) FROM t_order WHERE update_time ${CHECK_DATE}; -- 目标库同样条件 SELECT COUNT(*), IFNULL(SUM(order_amount), 0) FROM t_order WHERE update_time ${CHECK_DATE};两个结果对比数量或金额对不上就立刻报警。这个校验任务本身也用 DataX 跑或者直接写一个独立的 Shell 脚本连两个库查询。别小看这一步它能帮你发现 90% 的同步问题而且是在用户发现之前。6.2 监控同步延迟和任务状态如果是 Canal/Debezium 这种实时同步方案一定要监控消费延迟。Canal 的metrics接口可以查到delay指标单位是毫秒代表从 binlog 产生到处理完成的时间差。设置一个阈值比如超过 5 秒告警可以第一时间发现问题。DataX 这类批次同步任务监控方式更简单查任务的退出码和日志关键字。Shell 脚本里每次执行完检查退出码非 0 就发告警。群晖场景下的任务计划也支持邮件通知可以勾选运行失败时发送邮件。6.3 幂等设计怎么都不为过无论你用哪种同步方案一定要牢记同步任务一定会重跑重跑必须不产生脏数据。数据库同步不是跑一次就完的事情网络抖动、目标库锁等待、磁盘满……任何一个因素都能让任务中断而任务中断后的第一反应一定是手动重跑。如果任务没有幂等设计重跑一次就多一份脏数据。DataX 场景下的幂等靠preSql先删后插Canal 场景下靠目标端的 upsert 逻辑ON DUPLICATE KEY UPDATESQL Server 事务复制场景下靠复制本身的事务语义。每种方案都有对应的手法关键是意识要先到位。7. 免费工具的真实边界什么时候该放弃免费方案虽然题目是免费数据库同步软件但作为老实话我还是要说清楚免费工具的边界在哪避免你踩了大坑才醒悟。免费方案撑不住的场景通常是这几个跨云混合同步 严格的数据一致性保障比如 AWS 的 MySQL 同步到阿里云的 PostgreSQL中间还要求不丢一条、不重复一条。免费工具能做到但需要极其复杂的补偿机制运维成本远超商业产品。超大规模单表十亿级以上 实时 多对一汇聚这种场景对同步工具的调度、监控、断点续传、数据回溯能力要求极高免费方案基本靠人肉救火。需要图形化监控大屏、拖拽式配置、报警工单联动这类企业级体验是商业产品如 NineData、Tapdata Cloud 等的核心卖点免费工具天生不具备。但绝大多数中小团队和个人开发者数据量在百万到千万级别单机或三五台服务器规模免费方案完全够用。DataX Canal 数据库原生复制这三个组合已经覆盖了日常 95% 的同步需求。核心不在于工具本身而在于你有没有把同步的边界条件想清楚——增量字段是什么、任务失败怎么办、数据对不对得上。根据我自己的实测经验一套 DataX 多实例增量同步在百万级数据量下单批次同步时间基本在几分钟内加上校验任务的总时长也不会超过 15 分钟放在凌晨执行完全无感。Canal 的实时同步链路从 binlog 产生到目标库可见实测通常在 100 毫秒到 1 秒之间完全对得起免费这个价格。