MySQL主从复制与读写分离：从原理到故障排查的完整落地指南

先说一个我常被问到的场景：业务流量涨上来，数据库CPU先报警，慢查询多起来，缓存命中率开始往下掉，领导一句“把主从复制和读写分离做了吧”就甩过来了。不少开发朋友一听MySQL主从复制与读写分离，第一反应是DBA的事，跟自己没多大关系。实际落地过程中，从binlog策略、复制账号权限、从库数据对齐，到中间件选型、延迟监控、故障恢复，每一步都可能踩出坑，而这些恰恰是开发、运维、架构都要一起扛的活。这篇文章，我结合自己的实践把整套东西掰开揉碎讲清楚——从复制原理到搭建步骤，从读写分离接入方式到故障排查链路，尽量让看完的人能直接落地复现。

坦白说，主从复制并不难，难的是理解它为什么这样设计、哪些环节容易出问题、出了问题该怎么一步步定位。如果你正准备在生产环境搭主从，或者团队里已经在用但总出延迟、丢数据、复制中断的怪问题，这篇文章应该能帮你省不少弯路。

1. 先把一件事想清楚：单库到底是怎么撑不住的

很多人把主从复制当成一个“标配架构”来上，上来就问怎么配，配完之后发现延迟高、读压力大的问题依旧，然后开始怀疑方案本身。其实主从复制不是万能药，它解决的问题非常具体：把读请求从主库上挪走。

1.1 为什么读压力会先于写压力击垮数据库

MySQL单实例的写能力在绝大多数业务场景下并不差，几千TPS的写入只要索引合理、事务不长，一台配置达标的机器完全能扛。真正先撑不住的大多是读：一个列表页可能同时触发几十张表的查询，一个热门活动接口的QPS可以轻松是写入接口的几十倍。当查询并发上去之后，InnoDB的buffer pool、磁盘IO、CPU解析开销、锁竞争都会急速恶化，最终影响的不只是读，连写也被拖下水。

这种情况下最直接的做法是加缓存，把热点数据放进Redis。但缓存解决不了三类问题：一是缓存未命中的冷数据查询依然会压到数据库；二是大量后台统计、报表类SQL不会走缓存，它们全表扫起来能把IO打满；三是多个业务方直连同一个库，谁也控制不住别人怎么写SQL。我见过一个生产事故，数据量刚过千万，一张表的统计查询在业务高峰期跑了将近两分钟，直接把主库的IO拖到100%，所有写入全部排队。这时候才反应过来，需要把读流量从主库上拆出去。

1.2 主从复制的本质：三个线程加一份binlog

理解MySQL主从复制，先忘掉那些花哨的集群方案，核心就一句话：主库把变更记录写到binlog，从库把binlog拉过来，重新执行一遍。

具体落地由三个线程完成：

• 主库上的dump线程：负责响应从库的拉取请求，读取主库binlog并推送过去。这里要特别注意，它是从当前读取点位向后推送，如果从库落后太多，dump线程要读的binlog文件可能已经被清理，从库就会报Got fatal error 1236这类错误。
• 从库上的IO线程：负责连接主库，接收binlog内容并写入从库本地的relay log（中继日志）。
• 从库上的SQL线程：负责读取relay log，把里面的每条事务在从库上重新执行。

这中间最值得琢磨的是异步复制带来的时间差：主库提交事务成功，并不代表从库已经执行完。压力大的时候，从库延迟几秒甚至几十秒都是可能的。读写分离的业务如果完全无视这个时间差，用户刚提交完订单就在从库查订单状态，大概率会查到旧的甚至查不到。这个问题的应对我会在第4部分详细讲。

1.3 什么样的业务不适合一上来就上读写分离

经验之谈，以下几种情况先别急着拆，拆了只会更痛苦：

• 写占比很高、读占比很低的系统。比如纯粹的后台订单处理系统，读QPS本来就不高，加从库只会增加复制延迟的把控成本，收益有限。
• 业务对数据一致性极其敏感，读操作绝不能容忍毫秒级延迟。一些金融类核心交易场景刚做完写入就要立刻读取并参与后续决策，这种强一致需求应该走主库，或者引入分布式事务中间件，而不是靠读写分离硬扛。
• SQL写得烂。一张表没有合适索引，在从库上跑同样的烂SQL，从库一样会被拖垮。原来只拖垮一个实例，拆完之后变成拖垮主库加从库，问题规模反而翻倍。我建议先把慢查询日志打开，把主要查询的explain过一遍，确认没有明显烂SQL之后再去做架构拆分。

判断做不做读写分离，我用的笨办法很简单：把慢查询数量、平均查询耗时、读QPS、主库CPU这四类指标放到一张趋势图里观察半个月，如果读QPS上涨时主库CPU和慢查询明显同步飙升，且缓存已经加过一轮还是压不住，再动手拆。顺序不要搞反，否则你会在排查问题时发现缓存没做好、索引没优化，却把锅甩给复制架构。

2. 从零搭建MySQL主从：我的完整步骤与参数解释

下面用一套我实测过的流程来演示。版本以MySQL 8.0为例，两台实例可以都是物理机，也可以在Docker里跑，但思路完全一样。我假设主库IP为192.168.1.10，从库IP为192.168.1.11。

2.1 主库和从库最基础的配置参数

主库my.cnf中重点关注这些参数：

ini复制[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 512M

从库my.cnf：

ini复制[mysqld]
server-id = 2
relay_log = relay-bin
log_bin = mysql-bin
log_slave_updates = ON
read_only = ON

有几个细节说一下为什么。

• server-id在整个复制拓扑里必须唯一。只要两个实例的server-id相同，从库IO线程连接主库后就会被直接断开，日志里只会报一条普通的连接错误，排查起来非常隐蔽，新手很容易忽略。
• binlog_format = ROW是8.0的默认值，但如果你是从5.7迁移过来的老库，很可能是STATEMENT或MIXED。从安全角度强烈建议用ROW，虽然binlog文件会变大，但每行变更前后都有记录，从库重放不依赖SQL上下文，出现数据不一致的概率低很多。
• 从库上的log_slave_updates = ON意味着从库执行完relay log后还会把自己生成的binlog记下来。如果将来要从这个从库再扩展一个二级从库，或者做级联复制、备份恢复，这个参数就很重要。现在不开，以后想开要重启实例。
• expire_logs_days在8.0已经标记为废弃，官方推荐用binlog_expire_logs_seconds替代。比如只保留3天，写成binlog_expire_logs_seconds = 259200。但很多存量环境还是沿用expire_logs_days，这无所谓，能用且清楚就行。

2.2 创建复制账号，权限给最小化

复制账号的权限不需要给全部，只需要REPLICATION SLAVE和REPLICATION CLIENT。

sql复制CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'your_strong_password';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

这里有个常见的坑：MySQL 8.0默认认证插件是caching_sha2_password，老版本客户端或者某些图形工具连接时可能报Authentication plugin 'caching_sha2_password' cannot be loaded。从库连接主库时如果遇到这个问题，最简单的处理是创建账号时指定mysql_native_password：

sql复制CREATE USER 'repl'@'192.168.1.%' IDENTIFIED WITH mysql_native_password BY 'your_strong_password';

我个人的建议是，如果复制两边都是8.0，直接用默认插件即可，别为了兼容旧客户端把密码插件改来改去，反而更不安全。

2.3 从库首次同步的数据对齐流程

这一步最容易被图省事的人跳过，以为直接从某个时间点配置主从就能自动补齐数据。大错特错。如果主库已经有存量数据，而你又没有提前备份恢复到从库，那么从库启动复制后会从复制点位开始重放binlog，如果这个点之前的表结构和数据在从库上不存在或不一样，SQL线程立刻报错。

我的标准操作流程是：

1. 在主库执行FLUSH TABLES WITH READ LOCK，拿到全局读锁。这一步是为了保证备份期间数据不变化，能拿到一致的备份点位。
2. 在另一个会话执行SHOW MASTER STATUS，记录当前binlog文件名和点位，比如mysql-bin.000003，Position: 8321。
3. 用mysqldump对全库做备份。数据量不大可以直接：

   bash复制mysqldump -uroot -p --single-transaction --master-data=2 --all-databases > backup.sql
   

4. 备份完成后释放读锁：UNLOCK TABLES。
5. 把备份文件传到从库，执行mysql -uroot -p < backup.sql完成恢复。

要注意，--single-transaction和--master-data=2的组合非常实用。前者用InnoDB多版本并发控制来保证一致性快照，不需要长时间锁表；后者备份文件头部会自动写入CHANGE MASTER TO需要的binlog文件名和点位。所以如果你用了这个参数组合，其实第2步的SHOW MASTER STATUS记不记都行，恢复完直接在备份文件头部找到对应的MASTER_LOG_FILE和MASTER_LOG_POS字段即可。

2.4 在从库执行CHANGE MASTER并启动复制

确认从库数据恢复完成之后，执行：

sql复制CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='your_strong_password',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=8321;

START SLAVE;

然后看状态：

sql复制SHOW SLAVE STATUS\G

重点关注三个字段：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: 0

如果IO线程是Connecting，大概率是网络不通、账号不对或者server-id冲突；如果SQL线程是No，去从库的SHOW SLAVE STATUS结果里找Last_SQL_Error字段，那才是根本原因。

我习惯在START SLAVE之后再执行一次：

sql复制SHOW PROCESSLIST;

确认能看到两个线程，主库那边也能看到对应的dump线程。看到这些才算真正跑起来。

3. 读写分离落地：应用直连还是中间件，怎么选

主从复制搭好只是第一步，业务侧的读流量从哪条路走到从库，才是“读写分离”能不能真正生效的分水岭。不同规模、不同团队能力，适合的接入方式差异非常大。

3.1 三种接入方式对比

有人会问，代码层自己写一个@DataSource注解根据方法名判断读写不就行了吗？小项目这样做没问题，但随着业务增长，漏标注解的方法越来越多，写操作走从库导致的数据不一致问题会以一种极其隐蔽的方式出现——比如用户下单后刷新页面发现订单没了，这种问题在测试环境很难复现，上了生产才爆发。

我偏向建议，从项目一开始就引入中间件，哪怕初期规则简单。中间件带来的额外性能损耗其实很小，但路由规则的可维护性和团队协作边界会清晰很多。

3.2 用MySQL Router实现一个最小可用配置

MySQL Router配置简单，适合快速上手。

假设主库是192.168.1.10:3306，从库是192.168.1.11:3306，Router装在同一台应用服务器上，监听6446端口（读写）和6447端口（只读）。

ini复制[routing:read_write]
bind_address = 0.0.0.0
bind_port = 6446
mode = read-write
destinations = 192.168.1.10:3306

[routing:read_only]
bind_address = 0.0.0.0
bind_port = 6447
mode = read-only
destinations = 192.168.1.11:3306

启动后应用连接读写库时用jdbc:mysql://127.0.0.1:6446/你的库名，连接只读库时用jdbc:mysql://127.0.0.1:6447/你的库名。

注意，Router这种基于端口的分离方式，本质上还是应用层自己约定读写走哪个端口，不是真正自动识别SQL类型。但大多数人并不需要SQL级识别，在代码里规划好mapper层哪些走只读端口、哪些走读写端口，反而更容易理解和维护。真正要实现根据SQL语句自动路由，就得用ShardingSphere或ProxySQL这类能解析SQL的中间件。

3.3 事务内读写分离的三个环境坑

不管用哪种方式落地，有3个环境层面的坑必须提前处理。

第一个是read_only参数。从库只读是要在MySQL层强制打开的，否则某个开发不小心连错实例，一条UPDATE就把主从数据打乱了。在从库配置里加上：

ini复制read_only = ON
super_read_only = ON

super_read_only连超级管理员账号的写操作也禁止，防止DBA自己手滑。

第二个是连接池配置。很多连接池默认连接复用不区分读写，容易把本来该走从库的查询通过连接池里的旧连接发到主库上。这需要确保从库对应的数据源连接池和主库的数据源完全隔离，不要偷懒共用一个连接池。

第三个是事务边界。如果你在业务代码里开了事务，那这个事务里的所有SQL最好全部走主库。原理不复杂：一个事务里读取的数据要能和事务内的写入保持一致，而在异步复制环境下从库可能还没同步到当前状态。我在代码规范里通常要求，任何@Transactional注解范围内禁止使用只读数据源。

3.4 从库只读之后，线上账号的权限也要同步收敛

MySQL层把从库设置成只读还不够，应用账号权限照样该收则收。比如只读账号的权限只给SELECT, SHOW VIEW，写入账号只给读写库的数据源。实际工作中我看到很多团队把同一个应用账号同时配给读库和写库，MySQL层的read_only阻止了意外写入，但在代码层面如果有人拿到这个账号去连别的实例，权限依然过大。

把权限收敛到最小，主从复制加上读写分离这层架构才算整体干净。

4. 延迟、中断、不一致：主从架构最常见的三种故障

从库搭好、读写分离上线，不代表事情结束了。主从架构的常态恰恰是“时不时出点问题”。这里我把实践中最常见的三种故障类型各写一个典型案例，把排查链路完整走一遍。

4.1 从库延迟：一条慢查询引发的雪崩

现象是业务侧开始大面积反馈刚写完的数据查不到，监控里看到Seconds_Behind_Master一路飙升到几十秒。

先别急着骂复制效率，第一步去看从库的SHOW PROCESSLIST。结果发现SQL线程卡在一条大查询上，这条查询不是复制产生的，是有人把报表任务直连了从库。这条报表SQL本身要扫几百万行做聚合，大概要跑40秒，期间SQL线程执行binlog回放只能排队等它，延迟自然越堆越高。

排查链路：

1. 定位慢SQL来源，先停掉或改到独立的分析库执行；
2. 从库加上监控账号的权限限制，禁止接非业务查询；
3. 在从库开启long_query_time = 1并接慢查询日志，及时发现同类问题。

从库本身也是数据库，它一样会因为烂SQL被拖垮。很多人以为从库同步慢是网络带宽或MySQL复制机制的问题，结果排查半天发现是有人在从库上跑分析查询，这个坑我见过不少次。

4.2 SQL线程停止：主键冲突和半路改表

另一个高频故障是Slave_SQL_Running: No。一个典型案例：从库延迟较大时，主库上有人删了一张表的某一行数据，binlog同步到从库时还没执行完毕，但运维此时手动在从库执行了同一条DELETE，等到SQL线程真正回放这条binlog时发现对应行已经不存在，直接报错停止。

或者另一种经典情况：从库上因为应用连错环境，误删了某一行主键数据，主库恰好随后更新了这行，SQL线程回放UPDATE时发现更新不到任何行（ROW模式下不报错，但如果主键冲突则会报错），总之错误日志会告诉你到底卡在哪。

修复思路不是直接START SLAVE硬续，常见做法是：

1. 看Last_SQL_Error确认错误内容；
2. 如果是主键冲突，说明从库多了行数据，可以在从库手动删除那行冲突数据，然后START SLAVE；
3. 如果是更新不到行，说明从库少了数据，评估这行数据是否重要，重要就做主库到从库的单行补录；
4. 如果错误堆积太多无法逐条处理，可以考虑STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;跳过一条。但这只是权宜之计，连续跳过会导致数据差距越来越大。

这种场景我强烈建议，宁可多花点时间逐条核对修复，也不要无脑跳过。跳过的每一条错误都意味着主从数据少了一次同步。

4.3 数据不一致：平时不查，一出事就是大事

MySQL主从复制在异步模式下，无法百分之百保证数据一致。硬件故障、异常断电、从库回放错误、人为在从库写入数据，任何一环都可能让主从数据出现偏差。

真正的经验是：要对一致性做定期巡检，别等到出事故才去发现。常用工具是pt-table-checksum，这是Percona Toolkit里的工具，可以在线对比主从数据，不会对业务产生太大影响。

基本用法：

bash复制pt-table-checksum h=192.168.1.10,u=root,p=your_password \
--databases=your_db \
--replicate=your_db.checksums

它会逐表对比主从数据，把不一致的结果写到checksums表里。发现不一致后，用pt-table-sync做订正：

bash复制pt-table-sync h=192.168.1.10,u=root,p=your_password \
--replicate=your_db.checksums \
--execute

这个工具会把从库数据改成和主库一致，前提是你已经确认主库数据是权威版本。我曾经在巡检中发现某张表有三行数据不一致，原因就是半年前有人在上线脚本里直连从库做过一次批量UPDATE，但当时没有开启read_only，所以直接写进去了，一直到巡检才发现。之后我把所有从库都加上了super_read_only，再也没出现过这种问题。

4.4 半同步复制：要不要启用，怎么取舍

延迟再低、排查再及时，异步复制在极端情况下仍然有丢数据的可能：主库写完binlog、事务提交成功，但binlog还没来得及传给从库时主库宕机，这部分数据就丢了。为了降低这种风险，MySQL提供了半同步复制。

半同步复制的基本逻辑是：主库提交事务时，必须等待至少一个从库确认收到了binlog并写入relay log，事务才算提交成功。这样主库宕机时，已经提交的事务至少存在于一个从库上，数据丢失的概率大大降低。

MySQL 8.0启用半同步需要在主从库都安装插件：

sql复制INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

注意8.0里插件名从master改成source，从slave改成replica。如果是5.7，则用rpl_semi_sync_master_enabled。

启用半同步后，如果从库迟迟不确认，主库会等待rpl_semi_sync_source_timeout毫秒后自动退化为异步复制，保证主库可用性。这个超时时间默认10秒太长了，生产环境我会设成1000毫秒左右，不让主库被拖太久。

是否启用半同步，取决于业务对数据安全的要求。核心交易类建议启用，日志、报表类可以不开，因为多一次网络往返确实会带来写性能损耗，虽然通常不到10%，但高并发写入场景也要实测验证。

5. 复制日常巡检清单：我建议你直接抄作业

主从复制不是配置完就能睡大觉的，它更像是一个需要持续照看的系统。下面这张清单是我在多个项目里沉淀下来的巡检项，可以在监控系统里配成周期性任务，也可以写成脚本定期执行。

5.1 核心监控项与预期阈值

监控复制状态最土但也最有效的方式，就是定时去执行SHOW SLAVE STATUS然后解析关键值。Python脚本也简单，核心逻辑就是在从库上查询：

sql复制SHOW SLAVE STATUS\G

如果你是用Prometheus监控，mysqld_exporter本身就暴露了mysql_slave_status_slave_io_running和mysql_slave_status_sql_running这两个指标，接上告警规则就行。

5.2 几个容易忽略但非常重要的小点

第一，全量备份的任务千万别放在从库业务高峰时段。备份本身会读取大量数据页，影响从库查询性能，如果延迟本来就高，备份会把延迟推到天上。建议放在凌晨低峰期，并且每天检查备份文件是否能正常恢复，不能只有备份动作却没有还原演练。

第二，主库的binlog清理策略要结合全量备份的周期来定。如果每天凌晨做全量备份，binlog保留两天足够；如果一周才做一次全量，binlog只留一天，中间某天备份坏了，你就只能靠binlog恢复到备份点之后，但备份点之前的全量已经没有，会陷入无法完整恢复的境地。安全做法是binlog保留时间大于全量备份周期，而且备份文件至少要留存两个周期以上。

第三，从库数量不是越多越好。每加一个从库，主库就要多一个dump线程去推送binlog。虽然MySQL的dump线程在多数情况下并发支撑几十个从库没问题，但从库太多会导致主库的网络和IO开销明显上升，推广成本也随之增加。一般业务规模下，两到三个从库足够分摊读流量。如果读流量大到三个从库都不够，通常要考虑缓存层而不是无限加从库。

第四，版本升级要谨慎。跨大版本做主从（比如5.7到8.0），binlog格式和语法兼容性都可能出问题。我踩过5.7和8.0之间默认字符集排序规则不一致的坑，导致从库回放时索引选择变化，某些SQL性能急剧下降。非必要不跨大版本搭建复制链路，最好同版本或小版本差异可控，并先在测试环境完整演练一遍数据同步。

5.3 我个人的运维习惯

巡检脚本我会写成一个每分钟执行一次的小任务，只检查复制状态和延迟，异常就推送到告警群。数据一致性巡检不追求高频，每周跑一次就够了，毕竟它是全量对比，太频繁会影响性能。

另外，每次在主库执行DDL都要格外小心。虽然MySQL 8.0的Online DDL已经很成熟，但大表加索引期间依然会产生大量binlog，从库SQL线程回放DDL时通常会持有相关对象的元数据锁，极容易引发延迟甚至复制卡住。我的习惯是，大表DDL放到业务低峰期，并且在执行前把从库延迟先压到0附近再动手，DDL执行完以后持续观察延迟曲线，直到恢复平稳。

6. 最后说几个很多人会反复踩的认知误区

写到这里，主从复制和读写分离的核心链路基本都覆盖了。最后再把几个我经常在技术群里看到、或者在面试里被反复问到的认知误区集中讲一下，免得你在架构设计时跑偏。

第一个误区：以为主从复制能自动实现负载均衡。实际上MySQL原生复制不会帮你做任何负载均衡，它只是单向数据同步，读请求默认还是会打到主库。读写分离要么靠应用层代码路由，要么靠中间件，这跟复制机制本身是两回事。

第二个误区：把主从复制当成高可用方案。复制不等于高可用。主库宕机后，从库不会自动接管，需要人为把从库提升为主库，业务连接也要切换。这套故障转移逻辑需要额外的管理工具或脚本去实现，比如MHA、Orchestrator这类方案。很多人只搭了主从复制就以为数据库高可用无忧了，等主库真宕机才发现业务已经完全中断，这就是没分清两者的边界。

第三个误区：以为Seconds_Behind_Master为0就代表主从数据绝对一致。这个指标反映的是SQL线程执行relay log的落后秒数，它依赖从库自身的时间戳计算，有一定误差。而且它只反映复制延迟，不代表两边的数据绝对一致。要判断一致性，还是得靠校验工具去真正对比数据。

第四个误区：把binlog格式当成无所谓的小配置。5.7默认ROW，但很多老项目初始化时可能沿用了STATEMENT。STATEMENT格式在主库执行带NOW()或者UUID()这类非确定性函数时，binlog里只记录SQL语句本身，从库重新执行时生成的新值可能与主库不一致。ROW格式则直接记录每行数据变化后的值，能最大程度避免这类偏差。我接手过的项目里，只要发现从库数据和主库莫名不一致，第一件事就是确认binlog格式，至少有一半问题源于这个配置。

主从复制与读写分离这套东西，说难不算难，说简单也不算简单。真正考验人的是你能不能把每个环节背后的为什么想透，能不能在故障发生时冷静地从日志和状态里找到根因，并形成一套可持续的巡检与恢复机制。把前面这些步骤和思路走通一遍，下次不管是新搭一套环境，还是排查一个诡异的主从问题，你都会比大多数人更有底气。