分布式系统如何同步MySQL数据库？，有哪些方案？

分布式系统下的MySQL数据库同步，核心答案是：根据一致性、延迟和架构需求，在主从复制、半同步复制、组复制和基于binlog的异构同步方案中做技术选型，并配套监控与容灾机制。

同步方案怎么选：先看业务场景再谈技术

很多团队一上来就搜“mysql数据库同步方案对比”，结果被一堆术语绕晕，其实选型没那么复杂，先回答三个问题：你能接受多少数据丢失？你的写入并发有多大？你的团队会运维哪种组件？

加载中

黑马MySQL数据库进阶教程，轻松掌握mysql主从复制从原理到搭建全流程

黑马Java

4.5万543143

原视频地址

• 主从异步复制：默认方案，主库提交事务后立即返回，从库异步拉取binlog，性能最好，但主库宕机时可能丢数据，适合日志、报表、读多写少的业务。
• 半同步复制：主库至少等一个从库确认收到binlog后才提交，性能损耗可控，基本不丢数据，适合订单、支付等核心交易系统。
• 组复制（MGR）：基于Paxos协议，多主或单主写入，强一致性，运维门槛高，对网络要求苛刻,适合金融级场景或需要多活写入的架构。
• 基于binlog的异构同步（如Canal、Maxwell）：不依赖MySQL原生复制，把binlog解析成JSON推送到Redis、Elasticsearch、Kafka等，适合数据异构和缓存更新。

行业共识认为，绝大多数业务用半同步复制就能满足99%的可靠性需求,不需要盲目上组复制。

单主复制和多主复制分别适合什么场景

单主复制最简单，一个主库负责写，多个从库分摊读，你只需要改连接池配置和读写分离中间件，就能实现水平扩展读能力，多主复制（双主互备）常见于机房容灾，两边都能写，但冲突处理麻烦，除非用MGR,否则不建议自己实现双主。

MySQL 8.0和5.7的同步差异

MySQL 8.0默认使用caching_sha2_password认证插件，5.7的从库直接连8.0主库会报认证错误，升级时记得先改plugin，另外8.0的binlog增加了即时回放能力，从库追进度更快，如果你还在5.7，建议优先考虑升级到8.0,同步性能和安全性都有明显提升。

主从复制配置实操：从零到一搭一套能用的

网上教程很多，但大多缺关键参数，下面这套操作基于MySQL 8.0，CentOS 7环境，主库IP假设为192.168.1.10，从库IP为192.168.1.11。

主库配置步骤

1. 编辑/etc/my.cnf，在[mysqld]段下加入：

server-id=1
log-bin=mysql-bin
binlog_format=ROW
binlog_row_image=FULL
expire_logs_days=7
sync_binlog=1

binlog_format=ROW是硬性要求,mixed模式在函数和存储过程场景下容易产生主子不一致。

创建复制专用账号：

CREATE USER 'repl'@'192.168.1.%' IDENTIFIED WITH mysql_native_password BY 'StrongPass_2026';
GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

查看当前binlog坐标：

SHOW MASTER STATUS;

记住File和Position两个值,后面要用。

从库配置步骤

1. 在/etc/my.cnf中加入：

server-id=2
relay_log=mysql-relay-bin
read_only=ON

read_only=ON只限制普通账号，不限制root和超级权限账号,实际业务账号要记得去掉写权限。

在从库执行：

CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='StrongPass_2026',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE;

检查状态：

SHOW SLAVE STATUS\G

重点看两项：Slave_IO_Running: Yes和Slave_SQL_Running: Yes，如果出现No，查看Last_IO_Error或Last_SQL_Error定位问题。

常见坑：主从延迟和断点续传

延迟排查用SHOW SLAVE STATUS里的Seconds_Behind_Master字段，如果这个值持续增长，先看从库磁盘IO和单线程回放瓶颈，MySQL 8.0可以启用replica_parallel_workers并行回放,设置成4或8能显著降低延迟。

断点续传不需要手动操作，通过relay_log自动实现，但如果relay_log_purge=1且relay log被误删，就得重新CHANGE MASTER TO，所以生产环境建议把relay_log_purge=0,保留日志以便排查。

半同步复制：让数据更安全但别拖垮性能

半同步是在异步复制基础上加了一层确认机制，主库在提交事务时，会等待至少一个从库把binlog写到relay log并返回ACK，然后才向客户端返回成功，这样即使主库崩溃，已提交的事务也至少存在于一个从库上。

开启半同步的具体操作

需要安装插件,主库和从库都要执行：

INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';

MySQL 8.0.26以后，插件名称从rpl_semi_sync_master改成了rpl_semi_sync_source,老命令会报错。

然后动态开启：

SET GLOBAL rpl_semi_sync_source_enabled = 1;
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

同时在my.cnf里固化配置,防止重启失效。

半同步的性能损耗和超时降级

半同步会增加一个网络往返的开销，在千兆局域网内，延迟通常增加5到1毫秒，如果业务对写入延迟极其敏感，可以设置rpl_semi_sync_source_timeout，超时后自动降级为异步，避免主库卡死，默认值是10秒,建议调成3000毫秒。

MGR组复制：强一致但不是银弹

MGR（MySQL Group Replication）是官方的高可用方案，基于Paxos算法实现多节点强一致，它允许单主模式或多主模式,节点之间通过内部消息传递进行状态机复制。

MGR适合哪些场景

• 需要自动化故障转移,不想搞MHA或Orchestrator。
• 需要多节点写入,比如分机房就近写入。
• 对数据一致性要求极高,主观上无法接受异步复制丢数据。

MGR的局限

• 组内节点数建议3个或5个，奇数节点才能避免脑裂,两个节点没有实质意义。
• 所有节点必须在同一局域网，延迟超过5毫秒就会频繁触发流控。
• DDL操作会阻塞整个组,大表DDL要分批处理。
• 不支持MyISAM,所有表必须用InnoDB。

如果你只是想解决主从切换问题，MGR有点重，用半同步+自动漂VIP的方案更轻量。

binlog异构同步：把数据分发到更多地方

MySQL原生复制只能同步到MySQL，但业务经常需要把数据同步到Elasticsearch做搜索，到Redis做缓存，到数据仓库做分析,这时候就要用Canal或Maxwell这类工具。

Canal工作原理

Canal伪装成从库，向主库发送dump请求，主库把binlog推送过来，Canal解析binlog后,按照你配置的规则投递到MQ或直接写入目标存储。

典型架构：

MySQL → Canal → Kafka → 消费者程序 → Elasticsearch / Redis / 数仓

好处是解耦，消费者可以独立扩缩容，坏处是链路变长，数据延迟可能从毫秒级变成秒级，如果业务对实时性要求不高,这是最灵活的方案。

实操：Canal快速部署

1. 下载Canal部署包并解压。
2. 修改conf/canal.properties，设置canal.serverMode = kafka。
3. 在conf/example/instance.properties里配置：

canal.instance.master.address=192.168.1.10:3306
canal.instance.dbUsername=canal
canal.instance.dbPassword=canal_pass
canal.instance.filter.regex=test_db\\..

启动Canal：

bin/startup.sh

消费Kafka topic,解析JSON格式的binlog事件。

注意账号权限：Canal需要SELECT、REPLICATION SLAVE、REPLICATION CLIENT三个权限。

同步监控和故障排查清单

同步不是配完就结束，日常运维才是大头，下面这份排查清单来自多年生产经验,按命中率排序。

高频故障原因

• 主从数据不一致：多半是早期用了binlog_format=MIXED，或者从库执行了手工写入，修复用pt-table-checksum和pt-table-sync，Percona Toolkit自带。
• 从库IO线程连不上主库：先telnet 主库IP 3306，再检查主库防火墙和bind-address。
• SQL线程报错Duplicate entry：主键冲突，说明从库有额外写入或数据不一致，跳过错误前先确认数据差异，不要盲目SET GLOBAL sql_slave_skip_counter=1。
• 磁盘空间不足：binlog和relay log增长过快，设置expire_logs_days和relay_log_purge。

监控指标推荐

如果你想用开源监控，Prometheus + mysqld_exporter自带复制监控项,告警规则也好配。

高可用切换：从主从复制到自动故障转移

单靠复制解决不了高可用，主库宕机需要自动切换，常用方案有MHA和Orchestrator，但MHA年久失修，推荐用Orchestrator + 半同步。

Orchestrator切换流程

1. Orchestrator检测到主库心跳丢失。
2. 从候选从库中选出数据最新的从库。
3. 提升该从库为新主库。
4. 其余从库自动CHANGE MASTER TO指向新主库。
5. 标清VIP漂移或更新DNS。

整个切换过程通常30秒内完成，前提是半同步开启,否则无法保证数据完全不丢。

切换后你要做什么

• 检查业务连接池是否重连成功。
• 确认新主库的read_only被关闭。
• 修改原主库配置,防止它重新加入集群后脑裂。
• 更新监控项里主库IP的标签。

数据一致性校验：不能只看复制状态

复制状态正常不代表数据一致，可能因为从库误操作、回放跳过错误等原因，数据已经悄悄产生了偏差，定期用pt-table-checksum做校验是必须的。

校验命令示例

pt-table-checksum --host=192.168.1.10 --databases=test_db --tables=orders --replicate=test_db.checksums --create-replicate-table

执行后查看checksums表，MASTER_COUNT和THIS_CNT不一致的记录就是差异行，修复前先备份，然后用pt-table-sync精准修复：

pt-table-sync --execute --databases=test_db --tables=orders --replicate=test_db.checksums h=192.168.1.11,D=test_db,t=orders

建议在业务低峰期执行,避免锁表影响线上。

分布式架构下的高级同步策略

当单机房扛不住流量时，你需要跨机房同步，这时候单纯的MySQL复制不够用,得结合业务改造。

双机房主主互备

两个机房各部署一套MySQL主从，通过binlog互相同步，问题在于双向复制会产生冲突，比如同一行数据在两个机房同时更新,解决方案：

• 按业务拆分：用户中心和订单中心分别指定不同机房为主。
• 用全局ID和时间戳做冲突检测,但实现复杂度高。
• 用MGR多主模式,让Paxos协议解决冲突。

分库分表后的同步

分库分表后，每个分片都是独立的MySQL实例，复制关系变成一对多或多对多，你可以用Canal把每个分片的binlog统一汇聚到大数据平台，做全量分析，也可以在每个分片内部做主从复制,独立高可用。

常见问题解答

如何判断当前MySQL主从复制是否正常？

登录从库执行SHOW SLAVE STATUS\G，确保Slave_IO_Running和Slave_SQL_Running均为Yes，且Seconds_Behind_Master不为NULL，如果该字段为NULL，说明IO线程未连接或配置有问题，同时观察该值是否持续增大,持续增大说明回放速度跟不上主库写入速度。

主从延迟严重时，应该优先调整哪个参数？

优先检查从库的replica_parallel_workers，MySQL 8.0默认单线程回放，多核机器浪费严重，设置为服务器的CPU核心数一半比较稳妥，其次检查从库磁盘类型，机械盘换成SSD能显著提升回放速度，最后检查主库是否在跑大事务,一个事务超过几百MB就会让从库延迟飙升。

Canal同步到Kafka，如何保证数据不丢失？

Canal把binlog解析后发送到Kafka时，需要设置acks=all和enable.idempotence=true，同时Canal自身有位置记录，重启后会从上次记录点继续消费，Kafka消费者端要手动提交offset，并保证业务处理逻辑幂等，比如用唯一键做去重,这样即使重复消费也不会产生脏数据。

分布式系统里的MySQL同步，没有万能方案，原生复制解决的是高可用和读写分离，半同步解决的是数据安全，MGR解决的是强一致，Canal解决的是异构分发，选型前先量化你的业务对一致性和延迟的容忍度，运维上务必加上监控和定期校验,否则再好的架构也会在某个凌晨悄悄出问题。