浅谈MySQL的主从复制机制

最新推荐文章于 2024-08-15 09:15:10 发布

A__Plus

最新推荐文章于 2024-08-15 09:15:10 发布

阅读量349

点赞数

分类专栏： MySQL

本文链接：https://blog.csdn.net/abc123lzf/article/details/89220069

版权

MySQL 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

引言

MySQL从3.23版本开始提供复制功能。复制功能能将主数据库上的DDL、DML操作通过日志的形式传送到从数据库，然后从数据负责执行这些日志中的操作，从而达到主从数据库的一致。

复制过程概述

（1）MySQL主库在事务提交时会将数据变更的操作作为事件记录在二进制日志中。
（2）主库主动推送二进制日志的信息到从库的中继日志文件中，之后从库根据中继日志文件的内容更新数据库。

在这里插入图片描述
MySQL通过3个线程来完成主从复制：其中Binlog Dump线程在主库上运行，IO线程和SQL线程在从库运行。
当复制过程开始时，首先创建IO线程与主库建立连接，主库随后创建Binlog Dump线程读取二进制日志文件并发送给IO线程，IO线程获取到数据后写入到从库的中继日志中，之后SQL线程获取中继日志的内容并写入数据库。

日志文件结构

从上述过程可以看出，主从复制涉及两个日志文件：二进制日志文件和中继日志文件。
在MySQL 5.0版本以后，二进制日志以事件的形式记录所有DDL、DML操作，每个Binlog事件由8个部分组成：
1、通用头（Common Header）、通用头的长度
通用头是二进制日志中所有事件的通用信息，它包含了事件的基本信息，例如事件类型和事件大小。
2、提交头（Post Header）、提交头的长度
提交头和事件类型有关，对不同事件的类型有着不同的提交头。
3、事件体
事件头后面就是事件体，其大小可变，负责存储事件的主要数据。
4、校验和
MySQL5.6版本以后的二进制日志提供了校验和功能，是一个32位的整型数，用于检查写入后是否有损坏。
5、二进制日志文件格式版本
用于标记日志文件的版本，在MySQL 3.23/4.0/4.1采用的是3号版本，MySQL 5.0之后的版本采用的是版本4。
6、服务器版本
表示创建该日志文件的服务器的版本字符串，包含服务器版本及特定Build信息。

这些Binlog事件存储在一系列二进制日志文件中，除此之外还有一个二进制日志索引文件，用来追踪已有的Binlog文件，以便在必要的时候服务器能够正常地创建新的Binlog文件，变更二进制文件的过程称为二进制日志轮换，只有4种行为会导致轮换的发生：
1、服务器停止
每次启动MySQL服务都会开始一个新的二进制日志
2、文件大小达到最大限制
如果日志文件太大，那么会自动轮换，可通过设置binlog-cache-size来控制Binlog文件大小
3、二进制日志被显式刷新
可通过FLUSH LOGS命令将所有日志写入磁盘，然后再创建一个新的文件继续写入日志信息。
4、服务器上发生事故

中继日志文件的文件格式、内容和二进制日志文件一样，区别在于当从库执行完中继日志中的内容后，会删除当前的中继日志文件。

两种常见主从架构

1、一主多从架构
在主库读取压力比较大的情况下，可以通过配置一主多从的架构实现读写分离，把大量对实时性要求不高的读请求分布到从库上，从而降低主库压力。在主库宕机情况下，可以将某个从库切换为主库继续服务，从而保证高可用。
在这里插入图片描述
2、多级复制架构
一主多从架构能够解决大部分读请求压力较大的应用场景，但是上述架构有一个问题就是主库的日志文件发送产生的IO会随着从库增加而增长，而多级复制架构解决了主库在从库过多的情况下的IO负载过大。
在这里插入图片描述
从图中可以看出，多主复制架构增加了一个二级主库，这个二级主库负责接收主库的日志内容，写入自身数据库，然后将数据变更写入日志分发给多个从库。然而这样也有一些缺陷：MySQL的复制是异步复制，当主库数据更新后，从库在一定时间内可能无法及时得到更新，这种架构不适合对一些时效性要求比较高的应用。