MySQL 主从复制机制详解：binlog 与 relay log 流程
文章目录
- MySQL 主从复制机制详解：binlog 与 relay log 流程
- 一、主从复制到底要解决什么问题？（一句话概念）
- 二、三线程 + 两日志：MySQL 复制的核心骨架
- 🔹 三个线程（3 threads）
- 🔹 两种日志（2 logs）
- 三、binlog：为什么主库必须用 binlog 做源？
- 四、从库 I/O Thread：binlog 是怎么传过去的？
- ① 给主库发送一个“读位置”请求（file + pos）
- ② Binlog Dump 线程开始推送数据
- ③ I/O 线程写入 relay log
- 五、从库 SQL Thread：relay log 是怎样被“重放”的？
- 六、复制能断点续传：binlog file + pos 的意义
- 七、为什么会有主从延迟？（提前挖个坑）
- 总结一句话
MySQL 主从复制机制详解：binlog 与 relay log 流程
大家好，我是程序员卷卷狗。
在真实的生产环境中，主从复制已经成为 MySQL 高可用体系中不可或缺的能力：既能做“读写分离”，也能做“故障切换”，更是分布式架构的根基。
然而，对大多数同学来说，binlog、relay log、I/O 线程、SQL 线程……这些概念非常抽象。
今天蒜皮就带你从“设计思想 → 执行流程 → 关键细节”把这件事讲到通透。
一、主从复制到底要解决什么问题？（一句话概念）
主从复制的目标非常简单：
把主库执行的所有操作，用日志的方式，准确且按顺序复刻到从库上。
它的出发点不是“提高性能”，而是“提高可靠性与扩展性”。
你可以把它理解为：
- 主库负责写入
- 从库负责阅读与抄作业
- 所有抄作业都必须 顺序一致、字迹工整、不能漏写、不能重复
因此，复制的核心是 顺序日志，而不是 SQL。
二、三线程 + 两日志：MySQL 复制的核心骨架
MySQL 复制的设计非常优雅，一句话总结就是：
主库产生 binlog → 从库 I/O 拉取 → 写到 relay log → 从库 SQL 重放
结构如下：
主库 从库
-----------------------------------------
业务执行 SQL
↓
写 binlog <------ I/O 线程（接收并写入 relay log）
↓
binlog dump 线程 ----→ relay log（中继日志）↓SQL 线程（应用）↓数据真正更新
整个流程依靠：
🔹 三个线程（3 threads）
- Binlog Dump（主库）：给从库推 binlog
- I/O Thread（从库）：拉取主库 binlog → 写入 relay log
- SQL Thread（从库）：执行 relay log → 同步数据
🔹 两种日志（2 logs）
- binlog（主库）：真实业务操作的“事实记录”
- relay log（从库）：从库本地的缓存日志，用来重放
只要这“五要素”稳住，复制就稳住。
三、binlog：为什么主库必须用 binlog 做源？
主库在执行事务时，会按顺序写入 binlog：
- SQL 执行
- 生成变更事件（event）
- 写入 binlog（顺序写盘）
- 事务 commit
关键注意：主库 commit = binlog 写成功
也就是说：
binlog 是主库事务成功的唯一证据。
因此，从库只要按顺序重放 binlog，就能得到与主库一致的数据，不会乱、不丢、不重放。
四、从库 I/O Thread：binlog 是怎么传过去的？
当从库启动复制后，它会做两件核心动作：
① 给主库发送一个“读位置”请求（file + pos）
比如：
mysql-bin.000015
offset = 987654
意思是：
“我从这里往后的 binlog，请发送给我。”
② Binlog Dump 线程开始推送数据
主库会从对应的 file + pos 开始，把 binlog 流式传给从库。
③ I/O 线程写入 relay log
从库拿到 binlog 事件后，立即写到：
relay-log.000001
relay-log.000002
relay-log.info（记录位置）
relay log 就像一个缓存池，用来给 SQL 线程消费。
五、从库 SQL Thread：relay log 是怎样被“重放”的？
SQL 线程会按顺序读取 relay log：
- 解析 event
- 找到对应的数据库、表、行
- 按主库的操作方式执行
- 完成真正的数据同步
你可以把 relay log 当成：
主库行为的“录像带”
而 SQL 线程就是：
从库播放录像的播放器
播完一帧算一帧，不会跳帧、不允许拖动、不允许倍速播放。
这也是为什么：
- 从库执行慢，会造成 主从延迟
- 从库压力大时会 越落越远
六、复制能断点续传：binlog file + pos 的意义
I/O 线程每同步一部分，会记录：
master_log_file = mysql-bin.000015
read_master_log_pos = 1234567
SQL 线程每执行一部分，也会记录：
relay_log_file = relay-log.000003
relay_log_pos = 888888
好处是：
- 从库宕机后可继续同步
- 主库重启不影响进度
- 不会重复执行
- 不会漏执行
这是复制机制能稳定运行十几年的关键。
七、为什么会有主从延迟？（提前挖个坑）
虽然这是下一篇的主题，但这里先给你铺垫几句，让你更容易理解复制运行机制：
主从延迟往往来自：
- SQL 线程执行不过来（单线程）
- 主库写入太快
- 大事务（比如一次 UPDATE 20 万行）
- 从库磁盘性能差
- 网络带宽或抖动问题
理解这些，有助于你后续掌握主从优化与高可用架构。
总结一句话
MySQL 主从复制不是“同步 SQL”，而是“同步顺序日志”。
binlog 是源，relay log 是缓存，SQL 线程是播放器。
整个系统依靠“三线程 + 两日志”稳定运行。