mysql数据同步是通过将源数据库的数据变更实时或准实时传输到目标数据库，实现多节点数据一致的技术，广泛应用于读写分离、数据备份、多机房部署等场景，不同同步方式的实现逻辑和适用场景存在明显差异。
mysql数据同步的核心原理
mysql所有数据同步方式都基于自身的日志机制实现，核心依赖binlog（二进制日志），binlog记录了所有对数据库进行增删改的操作，是数据同步的数据源。同步过程中，源端（主库）将binlog发送给目标端（从库），目标端重放binlog中的操作，从而实现数据一致。
常见的mysql同步方式
1. 异步主从复制
这是mysql最基础的同步方式，主库执行完客户端提交的事务后，立即返回结果给客户端，不等待从库接收和重放binlog，从库异步拉取主库的binlog进行同步。
配置步骤如下：
- 主库开启binlog，配置唯一server-id
- 主库创建用于同步的账号并授权
- 从库配置唯一server-id，指定主库地址、同步账号信息
- 从库启动同步线程，开始拉取主库binlog
示例配置主库my.cnf：
[mysqld] # 开启binlog，日志路径为/var/lib/mysql/mysql-bin log-bin=/var/lib/mysql/mysql-bin # 主库唯一标识，取值范围1-2^32-1 server-id=1 # binlog格式，推荐用ROW格式，记录每行数据变更，同步更准确 binlog_format=ROW # 同步时忽略的数据库，可选配置 binlog-ignore-db=information_schema binlog-ignore-db=performance_schema
主库创建同步账号：
-- 创建同步用户，允许从库IP连接 CREATE USER 'repl'@'192.168.0.%' IDENTIFIED BY 'repl_password'; -- 授予同步权限 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.%'; FLUSH PRIVILEGES; -- 查看主库binlog状态，记录File和Position值 SHOW MASTER STATUS;
从库配置同步：
-- 配置主库连接信息，替换对应的File和Position值 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; -- 启动同步 START SLAVE; -- 查看同步状态，Slave_IO_Running和Slave_SQL_Running都为Yes则同步正常 SHOW SLAVE STATUSG
这种方式的优点是主库性能影响小，缺点是如果主库宕机，未同步到从库的数据可能丢失，适合对数据一致性要求不高的场景。
2. 半同步复制
半同步复制是异步复制的增强版，主库执行完事务后，至少等待一个从库接收binlog并写入本地relay log（中继日志）后，才返回结果给客户端，兼顾了性能和数据安全性。
配置半同步复制需要先安装mysql的半同步插件：
-- 主库安装半同步插件 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; -- 从库安装半同步插件 INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; -- 主库开启半同步复制 SET GLOBAL rpl_semi_sync_master_enabled = 1; -- 从库开启半同步复制 SET GLOBAL rpl_semi_sync_slave_enabled = 1; -- 从库重启IO线程使配置生效 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
半同步复制在数据一致性上比异步复制更可靠，适合对数据丢失容忍度低的业务场景。
3. GTID同步
GTID（全局事务标识符）是mysql 5.6及以上版本支持的特性，每个事务都有全局唯一的标识，同步时从库不需要指定binlog的File和Position，只需要知道主库的GTID集合即可，避免了传统同步方式中主库切换后需要重新定位binlog的问题。
开启GTID的配置示例（主从库都需要配置）：
[mysqld] # 开启GTID模式 gtid_mode=ON # 强制GTID一致性，保证事务安全 enforce_gtid_consistency=ON # 其他基础配置和异步复制一致 log-bin=/var/lib/mysql/mysql-bin server-id=1 binlog_format=ROW
从库配置GTID同步：
CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_AUTO_POSITION=1; START SLAVE;
GTID同步简化了主从切换、故障恢复的操作，是目前生产环境推荐使用的同步方式。
4. 双主互相同步
双主同步是指两个mysql实例互为主从，都可以接收写请求，数据双向同步，适合需要多写节点的场景，但需要注意避免主键冲突，通常需要设置自增主键的步长和偏移量。
双主配置示例（两个实例server-id分别为1和2）：
-- 实例1配置 [mysqld] server-id=1 log-bin=/var/lib/mysql/mysql-bin binlog_format=ROW gtid_mode=ON enforce_gtid_consistency=ON # 自增主键偏移量，避免冲突 auto_increment_increment=2 auto_increment_offset=1 -- 实例2配置 [mysqld] server-id=2 log-bin=/var/lib/mysql/mysql-bin binlog_format=ROW gtid_mode=ON enforce_gtid_consistency=ON auto_increment_increment=2 auto_increment_offset=2
双主同步需要业务层做好冲突规避，否则容易出现数据不一致问题。
不同同步方式的对比
| 同步方式 | 数据安全性 | 主库性能影响 | 配置复杂度 | 适用场景 |
|---|---|---|---|---|
| 异步主从复制 | 低 | 小 | 低 | 读写分离、非核心业务备份 |
| 半同步复制 | 中 | 中 | 中 | 核心业务、对数据丢失敏感场景 |
| GTID同步 | 高 | 小 | 中 | 生产环境主从架构、故障自动切换场景 |
| 双主互相同步 | 中 | 中 | 高 | 多写节点、容灾场景 |
同步过程中的常见问题
- 同步延迟：从库重放binlog的速度慢于主库产生binlog的速度，可通过提升从库硬件性能、减少大事务、开启并行复制来缓解
- 数据不一致：大事务、网络中断、从库写入数据都可能导致不一致，可通过
pt-table-checksum工具定期校验数据，用pt-table-sync修复不一致数据 - 同步中断：主库binlog被清理、网络异常都会导致同步中断，需要先排查中断原因，修复后重新启动同步线程