MySQL主从同步是数据库架构中常用的高可用与读写分离实现方案，通过将主库的更新操作同步到从库，实现数据冗余备份、读写请求分流，提升整体系统的稳定性和处理能力。
MySQL主从同步核心原理
主从同步的核心依赖三个线程和两类日志文件，整体流程可以分为三个步骤：
- 主库将所有的数据变更操作记录到
binlog（二进制日志）中，binlog是主从同步的数据源 - 从库的IO线程连接主库，读取主库的
binlog内容，将其写入到从库本地的relay_log（中继日志）中 - 从库的SQL线程读取
relay_log中的内容，按照顺序执行这些SQL操作，完成数据同步
整个过程中，主库只负责写入binlog，从库的两个线程分别负责拉取日志和执行日志，两者互不干扰，这也是主从架构可以实现读写分离的基础。
MySQL主从同步配置步骤
1. 主库配置
首先修改主库的配置文件，开启binlog并设置唯一的服务ID：
[mysqld] # 开启binlog，指定日志文件前缀 log-bin=mysql-bin # 服务唯一ID，主从库ID不能重复 server-id=1 # 指定需要同步的数据库，不配置则同步所有库 binlog-do-db=test_db # 指定不需要同步的数据库 binlog-ignore-db=mysql
重启主库服务后，登录主库执行以下命令，创建用于从库同步的账号并授权：
-- 创建同步账号，密码为sync_pass CREATE USER 'sync_user'@'192.168.0.%' IDENTIFIED BY 'sync_pass'; -- 授予同步权限 GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'sync_user'@'192.168.0.%'; -- 刷新权限 FLUSH PRIVILEGES; -- 查看主库binlog状态，记录File和Position值 SHOW MASTER STATUS;
执行SHOW MASTER STATUS后会得到类似如下的结果，后续从库配置需要用到File和Position的值：
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
|---|---|---|---|
| mysql-bin.000001 | 154 | test_db | mysql |
2. 从库配置
修改从库的配置文件，设置唯一的服务ID：
[mysqld] # 从库服务唯一ID，不能与主库和其他从库重复 server-id=2 # 开启中继日志 relay-log=relay-bin # 从库只读，避免手动修改数据导致主从不一致 read-only=1
重启从库服务后，登录从库执行以下命令配置主从同步关系：
-- 配置主库连接信息，替换为实际的主库IP、同步账号、密码、主库binlog文件名和位置 CHANGE MASTER TO MASTER_HOST='192.168.0.10', MASTER_USER='sync_user', MASTER_PASSWORD='sync_pass', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; -- 启动从库同步线程 START SLAVE; -- 查看从库同步状态 SHOW SLAVE STATUSG
查看SHOW SLAVE STATUS的结果时，需要确认Slave_IO_Running和Slave_SQL_Running两个字段的值都为Yes，如果是则说明主从同步配置成功。
主从延迟的原因与解决方案
主从延迟常见原因
- 主库写入压力大，生成的
binlog速度超过从库IO线程拉取的速度 - 从库的SQL线程是单线程执行
relay_log中的操作，当主库有大事务或者批量操作时，从库执行速度跟不上 - 从库硬件配置低于主库，CPU、内存、磁盘IO性能不足，导致日志执行慢
- 从库上运行了其他耗时的查询或者业务操作，占用了SQL线程的执行资源
- 网络延迟导致从库IO线程拉取
binlog的速度变慢
主从延迟解决方案
针对不同的延迟原因，可以采用对应的优化方案：
- 如果是单线程SQL执行慢的问题，可以开启MySQL的多线程复制，MySQL 5.7及以上版本支持基于逻辑时钟的多线程复制，配置如下：
[mysqld] # 开启多线程复制，工作线程数为4 slave_parallel_workers=4 # 基于逻辑时钟的并行复制方式 slave_parallel_type=LOGICAL_CLOCK
- 优化主库的大事务，将大批量操作拆分为小批次执行，避免单个事务产生大量
binlog - 提升从库硬件配置，尤其是磁盘IO性能，建议使用SSD磁盘
- 避免从库执行耗时的查询操作，读写分离时尽量将耗时查询路由到专门的分析库，不要占用同步从库的资源
- 优化主从之间的网络环境，减少网络延迟
- 如果是业务对延迟不敏感，可以在从库查询时增加延迟判断，当延迟超过阈值时暂时将请求路由回主库
如果主从延迟已经产生，可以等待从库自动追平数据，或者如果是测试环境可以重新配置主从同步，重置从库的同步状态后重新指定主库的binlog位置。