当前位置: 首页 > 数据库 > 数据库综合 >正文

详细了解MySQL中的主备、主从和读写分离

来源:互联网时间:2021-09-01 19:00:48编辑:网友分享
本篇文章带大家了解一下MySQL中的主备、主从和读写分离,希望对大家有所帮助!
本篇文章带大家了解一下MySQL中的主备、主从和读写分离,希望对大家有所帮助!

一、MySQL主备的基本原理

详细了解MySQL中的主备、主从和读写分离
备库B和主库A之间维持了一个长连接。主库A内部有一个线程,专门用于服务备库B的这个长连接。一个事务日志同步的完整过程如下:

1.在备库B上通过change master命令,设置主库A的IP、端口、用户名、密码,以及要从哪个位置开始请求binlog,这个位置包含文件名和日志偏移量

2.在备库B上执行start slave命令,这时备库会启动两个线程,就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接

3.主库A校验完用户名、密码后,开始按照备库B传过来的位置,从本地读取binlog,发给B

4.备库B拿到binlog后,写到本地文件,称为中转日志

5.sql_thread读取中转日志,解析出日志里的命令,并执行

由于多线程复制方案的引入,sql_thread演化成了多个线程

二、循环复制问题

双M结构:

详细了解MySQL中的主备、主从和读写分离

1、什么是主备延迟?

与数据同步有关的时间点主要包括以下三个:

1.主库A执行完成一个事务,写入binlog,这个时刻记为T1

2.之后传给备库B,备库B接收完这个binlog的时刻记为T2

3.备库B执行完这个事务,把这个时刻记为T3

所谓主备延迟,就是同一个事务,在备库执行完成的时间和主库执行完成的时间之间的差值,也就是T3-T1

可以在备库上执行show slave status命令,它的返回结果里面会显示seconds_behind_master,用于表示当前备库延迟了多少秒

seconds_behind_master的计算方法是这样的:

1.每个事务的binlog里面都有一个时间字段,用于记录主库上写入的时间

2.备库取出当前正在执行的事务的时间字段的值,计算它与当前系统时间的差值,得到seconds_behind_master

如果主备库机器的系统时间设置不一致,不会导致主备延迟的值不准。备库连接到主库的时候,会通过SELECTUNIX_TIMESTAMP()函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致,备库在执行seconds_behind_master计算的时候会自动扣掉这个差值

网络正常情况下,主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差

主备延迟最直接的表现是,备库消费中转日志的速度,比主库生产binlog的速度要慢

2、主备延迟的原来

1.有些部署条件下,备库所在机器的性能要比主库所在的机器性能差

2.备库的压力大。主库提供写能力,备库提供一些读能力。忽略了备库的压力控制,导致备库上的查询耗费了大量的CPU资源,影响了同步速度,造成主备延迟

可以做以下处理:

  • 一主多从。除了备库外,可以多接几个从库,让这些从库来分担读的压力
  • 通过binlog输出到外部系统,比如Hadoop这类系统,让外部系统提供统计类查询的能力

3.大事务。因为主库上必须等事务执行完才会写入binlog,再传给备库。所以,如果一个主库上的语句执行10分钟,那这个事务很可能会导致从库延迟10分钟

典型的大事务场景:一次性地用delete语句删除太多数据和大表的DDL

四、主备切换策略

1、可靠性优先策略

双M结构下,从状态1到状态2切换的详细过程如下:

1.判断备库B现在的seconds_behind_master,如果小于某个值继续下一步,否则持续重试这一步

2.把主库A改成只读状态,即把readonly设置为true

3.判断备库B的seconds_behind_master的值,直到这个值变成0为止

4.把备库B改成可读写状态,也就是把readonly设置为false

5.把业务请求切到备库B

详细了解MySQL中的主备、主从和读写分离

表t定义了一个自增主键id,初始化数据后,主库和备库上都是3行数据。继续在表t上执行两条插入语句的命令,依次是:

insert into t(c) values(4);insert into t(c) values(5);

假设,现在主库上其他的数据表有大量的更新,导致主备延迟达到5秒。在插入一条c=4的语句后,发起了主备切换

下图是可用性优先策略,且binlog_format=mixed时的切换流程和数据结果
详细了解MySQL中的主备、主从和读写分离
因此row格式在记录binlog的时候,会记录新插入的行的所有字段值,所以最后只会有一行不一致。而且,两边的主备同步的应用线程会报错duplicate key error并停止。也就是说,这种情况下,备库B的(5,4)和主库A的(5,5)这两行数据都不会被对方执行

3、小结

1.使用row格式的binlog时,数据不一致问题更容易被发现。而使用mixed或者statement格式的binlog时,可能过了很久才发现数据不一致的问题

2.主备切换的可用性优先策略会导致数据不一致。因此,大多数情况下,建议采用可靠性优先策略

五、MySQL的并行复制策略

详细了解MySQL中的主备、主从和读写分离
coordinator就是原来的sql_thread,不过现在它不再直接更新数据了,只负责读取中转日志和分发事务。真正更新日志的,变成了worker线程。而worker线程的个数就是由参数slave_parallel_workers决定的

coordinator在分发的时候,需要满足以下两个基本要求:

  • 不能造成更新覆盖。这就要求更新同一行的两个事务,必须被分发到同一个worker中
  • 同一个事务不能被拆开,必须放到同一个worker中

1、MySQL5.6版本的并行复制策略

MySQL5.6版本支持了并行复制,只是支持的粒度是按库并行。用于决定分发策略的hash表里,key是数据库名

这个策略的并行效果取决于压力模型。如果在主库上有多个DB,并且各个DB的压力均衡,使用这个策略的效果会很好

这个策略的两个优势:

  • 构造hash值的时候很快,只需要库名
  • 不要求binlog的格式,因为statement格式的binlog也可以很容易拿到库名

可以创建不同的DB,把相同热度的表均匀分到这些不同的DB中,强行使用这个策略

2、MariaDB的并行复制策略

redo log组提交优化,而MariaDB的并行复制策略利用的就是这个特性:

  • 能够在同一个组里提交的事务,一定不会修改同一行
  • 主库上可以并行执行的事务,备库上也一定是可以并行执行的

在实现上,MariaDB是这么做的:

1.在一组里面一起提交的事务,有一个相同的commit_id,下一组就是commit_id+1

2.commit_id直接写到binlog里面

3.传到备库应用的时候,相同commit_id的事务分发到多个worker执行

4.这一组全部执行完成后,coordinator再去取下一批

下图中假设三组事务在主库的执行情况,trx1、trx2和trx3提交的时候,trx4、trx5和trx6是在执行的。这样,在第一组事务提交完成的时候,下一组事务很快就会进入commit状态

详细了解MySQL中的主备、主从和读写分离
在备库上执行的时候,要等第一组事务完全执行完成后,第二组事务才能开始执行,这样系统的吞吐量就不够

另外,这个方案容易被大事务拖后腿。假设trx2是一个超大事务,那么在备库应用的时候,trx1和trx3执行完成后,下一组才能开始执行。只有一个worker线程在工作,是对资源的浪费

3、MySQL5.7版本的并行复制策略

MySQL5.7版本由参数slave-parallel-type来控制并行复制策略:

  • 配置为DATABASE,表示使用MySQL5.6版本的按库并行策略
  • 配置为LOGICAL_CLOCK,表示的就是类似MariaDB的策略。MySQL在此基础上做了优化

同时处于执行状态的所有事务,是不是可以并行?

不可以,因为这里面可能有由于锁冲突而处于锁等待状态的事务。如果这些事务在备库上被分配到不同的worker,就会出现备库跟主库不一致的情况

而MariaDB这个策略的核心是所有处于commit状态的事务可以并行。事务处于commit状态表示已经通过了锁冲突的检验了
详细了解MySQL中的主备、主从和读写分离
图中,虚线箭头表示的是主备关系,也就是A和A’互为主备,从库B、C、D指向的是主库A。一主多从的设置,一般用于读写分离,主库负责所有的写入和一部分读,其他的读请求则由从库分担
详细了解MySQL中的主备、主从和读写分离
读写分离的主要目的就是分摊主库的压力。上图中的结构是客户端主动做负载均衡,这种模式下一般会把数据库的连接信息放在客户端的连接层。由客户端来选择后端数据库进行查询

还有一种架构就是在MySQL和客户端之间有一个中间代理层proxy,客户端只连接proxy,由proxy根据请求类型和上下文决定请求的分发路由
详细了解MySQL中的主备、主从和读写分离
2.第二种方法,对比位点确保主备无延迟:

  • Master_Log_File和Read_Master_Log_Pos表示的是读到的主库的最新位点
  • Relay_Master_Log_File和Exec_Master_Log_Pos表示的是备库执行的最新位点

如果Master_Log_File和Read_Master_Log_Pos和Relay_Master_Log_File和Exec_Master_Log_Pos这两组值完全相同,就表示接收到的日志已经同步完成

3.第三种方法,对比GTID集合确保主备无延迟:

  • Auto_Position=1表示这堆主备关系使用了GTID协议
  • Retrieved_Gitid_Set是备库收到的所有日志的GTID集合
  • Executed_Gitid_Set是备库所有已经执行完成的GTID集合

如果这两个集合相同,也表示备库接收到的日志都已经同步完成

4.一个事务的binlog在主备库之间的状态:

1)主库执行完成,写入binlog,并反馈给客户端

2)binlog被从主库发送给备库,备库收到

3)在备库执行binlog完成

上面判断主备无延迟的逻辑是备库收到的日志都执行完成了。但是,从binlog在主备之间状态的分析中,有一部分日志,处于客户端已经收到提交确认,而备库还没收到日志的状态
详细了解MySQL中的主备、主从和读写分离
上图从状态1到状态4,一直处于延迟一个事务的状态。但是,其实客户端是在发完trx1更新后发起的select语句,我们只需要确保trx1已经执行完成就可以执行select语句了。也就是说,如果在状态3执行查询请求,得到的就是预期结果了

semi-sync配合主备无延迟的方案,存在两个问题:

1.一主多从的时候,在某些从库执行查询请求会存在过期读的现象

2.在持续延迟的情况下,可能出现过度等待的问题

5、等主库位点方案

select master_pos_wait(file, pos[, timeout]);

这条命令的逻辑如下:

1.它是在从库执行的

2.参数file和pos指的是主库上的文件名和位置

3.timeout可选,设置为正整数N表示这个函数最多等待N秒

这个命令正常返回的结果是一个正整数M,表示从命令开始执行,到应用完file和pos表示的binlog位置,执行了多少事务

1.如果执行期间,备库同步线程发生异常,则返回NULL

2.如果等待超过N秒,就返回-1

3.如果刚开始执行的时候,就发现已经执行过这个位置了,则返回0
详细了解MySQL中的主备、主从和读写分离

6、GTID方案

 select wait_for_executed_gtid_set(gtid_set, 1);

这条命令的逻辑如下:

1.等待,直到这个库执行的事务中包含传入的gtid_set,返回0

2.超时返回1

等主库位点方案中,执行完事务后,还要主动去主库执行show master status。而MySQL5.7.6版本开始,允许在执行完更新类事务后,把这个事务的GTID返回给客户端,这样等GTID的方案可以减少一次查询

等GTID的流程如下:

1.trx1事务更新完成后,从返回包直接获取这个事务的GTID,记为gtid1

2.选定一个从库执行查询语句

3.在从库上执行 select wait_for_executed_gtid_set(gtid1, 1);

4.如果返回值是0,则在这个从库执行查询语句

5.否则,到主库执行查询语句
详细了解MySQL中的主备、主从和读写分离

更多编程相关知识,请访问:编程入门!!

以上就是详细了解MySQL中的主备、主从和读写分离的详细内容,更多请关注web开发者其它相关文章!

上一篇: 解析mysql的安装与使用(收藏)

下一篇:微软低调发布Visual Studio Code

您可能感兴趣的文章

相关阅读