一文搞懂 MySQL 主从复制

目录一、什么是 MySQL 主从复制主从复制的核心作用我们为什么要用它二、主从复制的底层原理大白话拆解全流程先搞懂 2 个核心文件再认识 3 个关键线程完整同步流程一步一步讲明白步骤 1主库写数据记录 binlog步骤 2从库 IO 线程拉取主库的 binlog步骤 3从库 SQL 线程重放中继日志步骤 4同步完成主从数据一致补充binlog 的 3 种格式一、什么是 MySQL 主从复制简单说MySQL 主从复制就是让一台主数据库Master和一台 / 多台从数据库Slave建立自动的数据同步关系主库上所有的数据变更增删改都会实时、自动地同步到从库最终主从库的数据完全一致。你可以把它理解成主库 公司总部的官方文档库所有内容的修改、新增都只能在总部完成从库 各个分公司的文档副本总部的文档一更新副本就自动同步分公司只能查阅不能私自修改。主从复制的核心作用我们为什么要用它读写分离扛住高并发业务里 80% 的请求都是查询读只有 20% 是增删改写。我们可以让主库只处理写请求所有读请求都分给从库相当于把数据库压力分散到多台机器瞬间就能扛住几倍的访问量这是它最常用的场景。数据热备份不怕误操作主库数据实时同步到从库相当于有了一个实时热备份。就算你在主库误删了数据从库还有完整的副本能快速恢复不用再靠几天前的冷备份哭唧唧。高可用实现故障容灾如果主库突然宕机我们可以立刻把一台从库切换成新的主库业务直接连新主库不用等主库修复大大缩短业务停机时间。业务隔离不影响核心服务比如你要做数据分析、报表统计这些操作非常耗资源如果直接在主库跑可能会把主库卡崩。这时候你可以在从库上跑这些操作就算从库跑满了也完全不影响核心业务。二、主从复制的底层原理大白话拆解全流程很多人一听到主从复制的原理就被三个线程、binlog、中继日志劝退了其实特别简单整个过程就像「总部发文件分店同步执行」全程只有 2 个核心文件、3 个关键角色、4 个核心步骤。先搞懂 2 个核心文件binlog二进制日志只存在于主库是主库的「操作流水账」。主库上所有对数据有修改的 SQL增删改事务提交后都会按顺序写到 binlog 里它记录了每一次数据变更的完整信息。relay log中继日志只存在于从库是从库的「中转文件柜」专门用来存放从主库拉取过来的 binlog 内容。再认识 3 个关键线程整个复制过程全靠这 3 个线程配合完成缺一不可主库的Binlog Dump 线程从库的IO 线程从库的SQL 线程完整同步流程一步一步讲明白步骤 1主库写数据记录 binlog当我们在主库执行一条增删改 SQL事务提交的时候主库会先把这次数据变更的详细信息按时间顺序写到 binlog 文件里。就像总部修改了产品价格先把这次修改的内容按顺序写到《总部操作流水账》里。步骤 2从库 IO 线程拉取主库的 binlog从库会主动和主库建立 TCP 连接然后从库的 IO 线程会给主库的 Binlog Dump 线程发请求「把你 binlog 里位置 xxx 之后的新内容发给我」。主库的 Binlog Dump 线程收到请求后会把 binlog 里对应的内容源源不断地发给从库的 IO 线程。从库的 IO 线程收到内容后不会直接修改数据而是先把它写到本地的 relay log中继日志里。就像分店的对接员找总部的快递员要最新的流水账快递员把文件发过来对接员收到后先放到店里的中转柜不直接改货架。步骤 3从库 SQL 线程重放中继日志从库的 SQL 线程会实时监控中继日志一旦发现中继日志里有新内容就会立刻把里面的操作在从库上完整地执行一遍。就像分店的理货员从中转柜拿出流水账照着上面的操作在店里的货架上同步修改价格、上下架商品保证分店和总部的货架完全一致。步骤 4同步完成主从数据一致当 SQL 线程执行完中继日志里的所有操作后从库的数据就和主库完全一致了。整个过程会不断循环主库一有新的变更就会自动同步到从库实现实时同步。补充一个关键点默认的主从复制是异步的。主库只要把 binlog 写好就会给客户端返回成功不会等从库同步完成。这也是主从延迟问题的根源后面会详细讲。补充binlog 的 3 种格式binlog 有 3 种记录格式直接决定了同步的稳定性STATEMENT语句级记录你执行的 SQL 语句本身。优点是日志体积小缺点是NOW()、UUID()这类函数会导致主从数据不一致现在基本不用了。ROW行级记录「哪一行的数据被改成了什么样子」不记录 SQL 语句。优点是绝对不会出现数据不一致稳定性拉满缺点是日志体积稍大。这是 MySQL 默认格式也是生产环境首选。MIXED混合模式上面两种的结合MySQL 自动判断用哪种格式一般不推荐。