MySQL主从复制 —— 作用、原理、数据一致性，异步复制、半同步复制、组复制

2025-02-06 188

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云数据库 Tair（兼容Redis），内存型 2GB

Redis 开源版，标准版 2GB

RDS MySQL Serverless 基础系列，0.5-2RCU 50GB

简介： MySQL主从复制作用、原理—主库线程、I/O线程、SQL线程；主从同步要求，主从延迟原因及解决方案；数据一致性，异步复制、半同步复制、组复制

文章目录

一、作用

二、原理

三、同步数据一致性

3.1 主从同步要求
3.2 主从延迟原因、直接表现
3.3 减少主从延迟的方案
3.4 数据一致性问题的解决
- 3.4.1 异步复制
- 3.4.2 半同步复制
- 3.4.3 组复制

MySQL主从复制的核心就是二进制日志binlog

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言，创建库、表）语句和 DML（数据操纵语言，增删改）语句，但不包括数据查询（SELECT、SHOW）语句。

一、作用

读写分离
数据备份
高可用性

二、原理

实际上主从同步是基于binlog进行数据同步的。在主从复制过程中，会基于3个线程来操作，一个主库线程、两个从库线程

二进制日志转储线程（Binglog dump thread）是一个主库线程，当从库线程连接时，主库可以将二进制日志发送给从库，当主库读取事件时，会在Binlog上加锁，读取完成后释放锁
从库I/O线程连接主库，向主库发送请求更新Binlog。这时从库的I/O线程就可以读取主库的二进制日志转储线程的Binlog更新部分，并且拷贝到本地的中继日志relaylog
从库SQL线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步

复制过程就是将binlog中的数据从主库传输到从库上，这个过程一般是异步的，即主库上执行事务操作的线程不会等待复制binlog的线程同步完成。主从复制概括为：在Master端开启binlog ，从库将master的binlog拷贝到它的中继日志relay log，slave端重放binlog 从而达到主从数据一致

简单来说分成三步：

写入binlog：Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中
同步binlog：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log（从库将master的binlog拷贝到它的中继日志）
回放binlog：slave重做中继日志中的事件，将改变应用到自己的数据库中

MySQL复制时异步且串行化的，重启后从接入点开始复制。

具体详细过程如下：

MySQL主库在收到客户端提交事务的请求之后，会先写入binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端"操作成功"的响应。
从库会创建一个专门的I/O线程，连接主库的log dump线程，来接收主库的binlog日志，再把binlog信息写入relay log的中继日志里，再返回给主库"复制成功"的响应
从库会创建一个用于回放binlog的线程，去读relay log中继日志，然后回放binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

在完成主从复制之后，你就可以在写数据时只写主库、读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。

从库数量增加，从库连接上来的/O线程也比较多，主库也要创建同样多的log dump线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。

所以在实际使用中，一个主库一般跟2~3个从库(1套数据库，1主2从1备主)，这就是一主多从的MySQL集群结构。