SQL跨服务器同步数据，稳定能落地的路子就三条：数据库原生复制（MySQL binlog、SQL Server 复制）、定时抽取工具（mysqldump、DataX、SSIS）、CDC实时捕获（Canal、Debezium），选哪条不看工具热度，看你能容忍的延迟、数据量级、以及源表有没有可靠的更新时间字段。
先把需求问清楚：同步、迁移、还是备份
很多人一上来就问工具,其实先要回答三个问题，答完，方案基本自己就浮出来了。
- 延迟要求：允许小时级，定时任务足够；要求秒级，得上复制或CDC；要求毫秒级且能接受双写改造，走消息队列。
- 数据量级：单表几万行，mysqldump直接灌；单表上千万行，全量要分批，增量必须靠位点。
- 方向与冲突：单向（A到B）最简单，双向就得处理主键冲突和回环，复杂度翻几倍。
行业共识认为,八成以上的跨服务器同步需求，本质上都是”单向增量同步”，只是被包装成了”实时数据同步”。
一个容易忽略的前置检查
源表如果没有自增主键,也没有更新时间字段，任何增量方案都会退化成全量比对，这时候先改表结构，比换工具管用得多。
MySQL跨服务器数据同步怎么配置：从binlog到定时脚本
MySQL这条路最成熟,两条分支：主从复制和定时导出。
主从复制：延迟最低的原生方案
适合要求秒级、且允许从库只读的场景。
- 主库配置文件开启二进制日志：
server-id=1、log-bin=mysql-bin、binlog_format=ROW。 - 主库建复制账号：
CREATE USER 'repl'@'%' IDENTIFIED BY '密码';再GRANT REPLICATION SLAVE ON . TO 'repl'@'%'; - 锁表取位点：
FLUSH TABLES WITH READ LOCK;SHOW MASTER STATUS;记下 File 和 Position，取完立刻UNLOCK TABLES; - 从库执行：
CHANGE MASTER TO MASTER_HOST='源IP', MASTER_USER='repl', MASTER_PASSWORD='密码', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; - 启动并检查：
START SLAVE;再看SHOW SLAVE STATUS\G，重点盯Slave_IO_Running和Slave_SQL_Running两个 Yes，以及Seconds_Behind_Master。
注意 binlog_format 必须是 ROW，STATEMENT 格式在跨版本、跨字符集场景下，很容易出现数据不一致。
定时同步：mysqldump 管道直灌
适合T+1、小时级，以及只同步部分表的场景，核心命令就一行：
mysqldump -h 源IP -u user -p --single-transaction --master-data=2 --set-gtid-purged=OFF 库名 表名 | mysql -h 目标IP -u user -p 库名--single-transaction 保证 InnoDB 表导出时的一致性快照，不会锁业务表。--master-data=2 会把位点写成注释，方便后面做增量续接。
两种方式怎么选
| 对比项 | 主从复制 | 定时管道导出 |
|---|---|---|
| 延迟 | 秒级以内 | 取决于调度周期 |
| 对源库压力 | 持续读binlog | 导出瞬间有IO峰值 |
| 是否要求同版本 | 建议一致 | 较宽松，跨大版本也能试 |
| 运维复杂度 | 中，要盯延迟告警 | 低，脚本加crontab |
| 适用数据量 | 大表长期同步 | 中小表、报表库 |
SQL Server两台服务器数据库定时同步怎么做
SQL Server 生态里，主流做法有三种，踩坑点各不相同。
链接服务器加代理作业
最轻量的做法,适合表不多、量不大的场景，先在目标库注册链接服务器：
EXEC sp_addlinkedserver @server='LinkSrc', @srvproduct='', @provider='SQLNCLI', @datasrc='192.168.1.20'; EXEC sp_addlinkedsrvlogin @rmtsrvname='LinkSrc', @useself='false', @rmtuser='sa', @rmtpassword='密码';
然后写增量语句,用 MERGE 或 UPDATE ... INSERT 组合，挂到 SQL Server Agent 作业里按分钟或小时跑，难点在于 MERGE 在并发下有死锁风险，量大的表建议拆成”先删后插”的小批次。
事务复制：更接近实时的选择
SQL Server 自带复制功能，走的是日志读取器加分发代理，在 SSMS 里右键”复制”→”新建发布”，选事务复制，配置分发库和订阅库即可，优点是不用写同步SQL，缺点是配置链路较长，出问题排查要从分发库的 distribution 库下手。
SSIS 适合做字段清洗
当两端表结构不一致、需要做字段映射、类型转换、脏数据过滤时，SSIS 包比纯SQL好维护，缺点是部署在服务器上需要额外的运行时，运维成本偏高。
跨服务器数据库同步工具怎么选
这一块是选型时最容易纠结的,把常见工具摊开对比：
| 工具 | 类型 | 增量能力 | 上手成本 | 适用场景 |
|---|---|---|---|---|
| DataX | 开源离线 | 靠SQL条件切分 | 低 | 异构库批量同步 |
| Canal | 开源CDC | 解析binlog，准实时 | 中 | MySQL到MQ/搜索 |
| Debezium | 开源CDC | 日志捕获，生态好 | 中高 | 大数据链路 |
| Kettle | 开源ETL | 定时增量 | 低 | 表结构变换多 |
| 商业同步工具 | 商用 | 断点续传完善 | 低 | 无专职DBA的团队 |
数据库同步工具收费吗？开源工具本身免费，但隐性成本在人力：搭一套稳定的 Canal 或 Debezium 链路，通常要一个熟悉 Kafka 的工程师盯着，商业工具按节点或数据量报价，年费从几万到几十万不等，具体看并发和节点数，采购前建议先跑两周POC。
自研脚本的边界在哪
用 Python 写个带 last_update_time 条件的轮询脚本，两三张表完全够用，表一多、字段一改、断点一丢，维护成本会迅速吃掉省下的时间，业内的经验线是：同步表超过十张，就该考虑标准化工具了。
实时同步的坑：数据库同步延迟高怎么排查
延迟告警响起时,按这个顺序看，通常十分钟内能定位。
- 看是不是大事务，一次更新几十万行的批量操作，会阻塞后面的所有事件，拆批提交，每批控制在几千行。
- 看从库回放线程，MySQL 5.7 以上开
slave_parallel_workers和slave_parallel_type=LOGICAL_CLOCK，多线程回放能明显压住延迟。 - 看有没有主键，无主键表的 ROW 格式更新，从库要全表扫描定位行，延迟会像滚雪球。
- 看网络，跨机房、跨云的带宽和抖动是硬伤，先测
iperf，再谈优化。 - 看目标端压力，目标库如果同时在跑报表查询，写入会被拖慢，读写分离或者错峰调度。
一个常被忽略的配置
max_allowed_packet 太小会导致大字段同步中断，报错信息还很含糊，两端都调到 64M 以上，能省掉不少排查时间。
一致性校验和回滚：别只盯着”同步成功”
同步任务显示绿色,不代表数据真的一致，定期校验是必须动作。
- MySQL 侧用
pt-table-checksum做块级校验，发现差异再用pt-table-sync修复。 - SQL Server 侧可以写
EXCEPT查询对比两边行集合，或者用CHECKSUM_AGG做快速指纹。 - 断点续传：CDC 类工具要保留位点文件，定时任务要落一张同步日志表，记录每次的起止时间和影响行数，出问题时能从最近一次成功的位点重放。
据微软官方文档,SQL Server 复制在订阅端可以重新初始化，但重新初始化期间订阅端数据不可用，生产环境要安排在维护窗口。
关于SQL跨服务器同步的常见疑问
SQL跨服务器同步两个数据库，网络不通或者只开了单向端口怎么办？
优先考虑”推”而不是”拉”，让源端主动把数据推到目标端，防火墙只需放行一个出方向，如果两端完全隔离，中间加一台跳板机做中转落盘，用文件方式交换增量数据，虽然土但可靠，同步频率低到天级时，这反而是最省心的方案。
SQL跨服务器同步两个数据表，数据量很大，第一次全量怎么跑不炸？
分批,按主键区间切，每批几千到几万行，每批之间 sleep 几百毫秒给源库喘口气，MySQL 可以用 --where="id BETWEEN x AND y" 控制 mysqldump 的范围；SQL Server 用 OFFSET FETCH 分页，全量跑完之后，把增量位点对齐，再开启增量任务，据工信部相关技术指引，跨机房数据搬迁应避开业务高峰，并保留可回退的完整快照。
SQL跨服务器同步用存储过程还是用现成工具，长期看哪个更省事？
同步逻辑稳定、表结构几年不变、只有两三张表，存储过程加作业足够，排查时SQL就是文档，一旦涉及异构数据库、字段映射、多表关联，或者要给别人交接，现成工具的配置文件和监控面板明显更好维护，判断标准很简单：接手的人能不能在半小时内看懂这条链路在做什么，看不懂就说明该换工具了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774630.html
