MySQL主从复制配置并不复杂，抓住主库开binlog、从库做change master、启动同步三步走就能跑通，但真正考验人的是架构选型和异常处理。
先说结论：MySQL主从复制本质是主库把binlog日志推给从库，从库通过relay log回放实现数据一致，这套机制已经稳定运行了二十多年，目前仍然是中小团队搭建读写分离、备份容灾最常用的方案，下面直接拆解完整配置流程和坑点。
为什么多数团队仍然选择MySQL主从复制
很多人纠结该上MGR还是继续用传统主从,行业共识认为：主从复制胜在简单、可控、跨版本兼容性好，MySQL 5.7和8.0的原生复制机制没有本质变化，网上大量的历史踩坑经验依然有效。
MySQL主从复制和MGR有什么区别
- 主从复制：异步或半同步，靠binlog推送，架构简单，延迟可控，适合读写分离场景
- MGR：组复制，多节点强一致，但部署复杂度高，网络抖动敏感，节点数量建议奇数
多数中小项目没有强一致要求,用主从复制可以节省大量运维精力，如果你在纠结怎么选择，读多写少、能容忍秒级延迟就直接上主从；如果业务需要对账、资金类强一致，才需要考虑MGR或其它方案。
MySQL双主和一主多从有什么不同
- 双主：两个节点互为主从，业务写入其中任意一台，常用于高可用切换，但需要处理自增主键冲突和脑裂问题
- 一主多从：单点写入，多台从库分摊读流量，架构清晰，故障切换需要人工或外部脚本干预
从实际使用场景看,一主多从覆盖了80%以上的需求，双主更像是高可用中间件（如MHA）的底层配置。
MySQL主从复制配置步骤详解
重点来了,这里用MySQL 8.0版本演示，5.7基本一致，全程需要两台服务器，假设主库IP是192.168.1.10，从库IP是192.168.1.11。
第一步：修改主库配置文件
在my.cnf或my.ini的[mysqld]段加入：
- server-id=1（必须全局唯一）
- log-bin=mysql-bin（开启二进制日志）
- binlog_format=ROW（行级复制，官方默认，兼容性最好）
- expire_logs_days=7（控制binlog保留时间，生产环境建议至少保留3天，便于从库追进度）
然后执行systemctl restart mysqld（不同发行版命令略有差异），重启完成后用SHOW MASTER STATUS确认binlog已经开启。
第二步：创建复制专用账号
在主库执行授权命令：
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'YourStrongPassword';
GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;注意MySQL 8.0默认认证插件是caching_sha2_password，如果你的从库版本较老，需要改用mysql_native_password，否则同步时会报认证错误。
第三步：备份主库数据并恢复到从库
这是最容易被忽略的一步,如果直接拿一个没有数据的空库做从库，复制过程会直接断裂，除非你只新建库不同步历史数据。
主流做法是用mysqldump或XtraBackup做物理备份：
mysqldump -uroot -p --single-transaction --master-data=2 --all-databases > master.sql- –single-transaction：InnoDB表拿到一致性快照，不锁表
- –master-data=2：自动记录SHOW MASTER STATUS的坐标，后面change master要用
把备份文件传到从库后执行mysql -uroot -p < master.sql恢复。
第四步：从库配置文件修改
从库需要配置：
- server-id=2（不能和主库重复也不能复用历史值）
- read_only=1（普通账号只读，防止应用误写）
重启从库服务后进入MySQL执行：
CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='YourStrongPassword',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=154;MASTER_LOG_FILE和MASTER_LOG_POS从备份文件头部或主库SHOW MASTER STATUS输出里获取。
第五步：启动复制并验证
START SLAVE;
SHOW SLAVE STATUSG;重点关注两个字段：
| 参数名 | 正常状态 | 含义 |
|---|---|---|
| Slave_IO_Running | Yes | IO线程正常拉取binlog |
| Slave_SQL_Running | Yes | SQL线程正常回放relay log |
如果两项都是Yes,复制就算建立成功了，可以通过在主库建测试表插入一条数据，在从库查询验证。
MySQL主从复制延时高怎么解决
做了主从之后最扎心的问题就是延迟,延迟产生的原因五花八门，排查方向比执行命令更重要。
排查思路和实用命令
先在从库执行SHOW SLAVE STATUS查看Seconds_Behind_Master字段，这个值接近0说明没有堆积，如果数值持续增长，按照以下顺序排查：
- 主库是否有大事务长时间运行（查information_schema.innodb_trx）
- 从库服务器CPU/IO是否被打满（用top和iostat看）
- 从库的binlog和relay log是否放在同一块磁盘
- 复制线程是否被慢查询拖累（打开慢查询日志定位）
解决主从延迟的实操手段
- 升级半同步复制：主库等从库确认收到binlog再提交事务，能在很大程度上缓解数据丢失风险，但对延迟改善有限
- 分库分表：把大库拆小，减少单个实例的复制压力
- 并行复制：在从库配置
slave_parallel_workers=4，8.0版本自动基于事务粒度分发，效果比较明显 - 硬件升级：换SSD、加大内存，让从库刷盘更快，是成本低见效快的土办法
行业共识认为,并行复制和硬件升级能解决大部分延迟问题，剩下少数场景得靠架构调整解决。
主从复制日常巡检和故障恢复
复制不会一劳永逸,跑生产环境每天花五分钟看一眼状态是基本功。
日常要盯的几个指标
- 主从延迟秒数
- 从库的IO线程和SQL线程状态
- 主库binlog磁盘占用
- 从库的relay log积压情况
常见异常之一是Slave_SQL_Running变No，原因可能是主库执行了从库不支持的语句，或者表结构不一致，处理方法是先查Last_Error定位报错，能修复数据就手动修复后执行STOP SLAVE; START SLAVE;让复制继续。
另一个高发问题是主库binlog被清理而从库还没拉取，这时需要重新做一次备份恢复，代价比较大，建议给从库监控加一个文件位置有效性的报警，别等复制彻底断开才发现。
MySQL主从复制配置常见问题
主从复制一定要用固定IP吗
推荐使用固定IP或内网域名,因为CHANGE MASTER语句里写的是主机地址，换IP后需要重新执行一次，云环境下优先用内网地址，不要穿越公网复制，延迟大还不安全。
从库能不能停掉binlog
可以关,但强烈建议开着，从库的binlog可以用作下一级从库的数据源，也可以作为备份恢复的补充，代价仅是额外磁盘占用，相比恢复数据的痛苦来说不值一提。
GTID复制和传统位点复制怎么选
MySQL 5.6以后推荐GTID，原因是故障切换后从库能自动找回正确的binlog位置，不需要人工拼接坐标，8.0默认就是GTID模式，新环境直接用GTID，老环境升级时再做对比评估也来得及。