MySQL高可用机制分析

本文阅读 10 分钟
首页 代码,Java 正文

  在一个主备关系中,每个备库接收主库的binlog并执行。

  正常情况下,只要主库执行更新生成的所有binlog,都可以传到备库并被正确地执行,备库就能达到跟主库一致的状态,这就是最终一致性。

  但MySQL要提供高可用能力,只有最终一致性是不够的。 img

  主备切换可能是一个主动运维动作,比如软件升级、主库所在机器按计划下线等,也可能是被动操作,比如机房停电。

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

  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。

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

  在网络正常的时候,日志从主库传给备库所需的时间是很短的(T2-T1很小),主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。所以主备延迟最直接的表现是,备库消费中转日志(relay log)的速度,比主库生产binlog的速度要慢。

2.1 备库所在机器的性能较差

  更新请求对IOPS的压力,在主库和备库上是无差别的,做这种部署时,一般都会将备库设置为“非双1”的模式。

  更新过程中也会触发大量的读操作,当备库主机上的多个备库都在争抢资源的时候,就可能会导致主备延迟了。

2.2 备库的压力大

  主库既然提供了写能力,那么备库可以提供一些读能力。或者一些运营后台需要的分析语句,不能影响正常业务,所以只能在备库上跑。

备库压力大时一般可以这么处理:

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

2.3 大事务

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

  一次性地用delete语句删除太多数据,就是一个典型的大事务场景。

  另一种典型的大事务场景是大表DDL。解决方案是计划内的DDL,建议使用gh-ost方案。( 《Mysql删除数据前后表文件大小相同》

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

  1. 判断备库B现在的seconds_behind_master,如果小于某个值(比如5秒)继续下一步,否则持续重试这一步;
  2. 把主库A改成只读状态;
    <li>判断备库B的seconds_behind_master的值,直到这个值变成0为止;</li>
  3. 把备库B改成可读写状态;
  4. 把业务请求切到备库B。

img

  这个切换流程中是有不可用时间的。因为在步骤2之后,主库A和备库B都处于readonly状态,直到步骤5完成后才能恢复。

  在这个不可用状态中,比较耗费时间的是步骤3,可能需要耗费好几秒的时间。所以需要在步骤1先做判断,确保seconds_behind_master的值足够小。

  系统的不可用时间是由数据可靠性优先的策略决定的。也可以选择可用性优先的策略,来把这个不可用时间几乎降为0。

  如果把步骤4、5调整到最开始执行,也就是说不等主备数据同步,直接把连接切到备库B,并且让备库B可以读写,那么系统几乎就没有不可用时间了。

  这个切换流程的代价,就是可能出现数据不一致的情况。

CREATE TABLE `t` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `c` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into t(c) values(1),(2),(3);

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

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

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

  图3是可用性优先策略,且binlog_format=mixed时的切换流程和数据结果。 img

  1. step2中,主库A执行完insert语句,插入了一行数据(4,4),之后开始进行主备切换。
  2. step3中,由于主备之间有5秒的延迟,所以备库B还没来得及应用“插入c=4”这个中转日志,就开始接收客户端“插入 c=5”的命令。
  3. step4中,备库B插入了一行数据(4,5),并且把这个binlog发给主库A。
  4. step5中,备库B执行“插入c=4”这个中转日志,插入了一行数据(5,4)。而直接在备库B执行的“插入c=5”这个语句,传到主库A,就插入了一行新数据(5,5)。

可用性优先策略,但设置binlog_format=row

  因为row格式在记录binlog的时候,会记录新插入的行的所有字段值,所以最后只会有一行不一致。而且两边的主备同步的应用线程会报错duplicate key error并停止。

img

  使用row格式的binlog时,数据不一致的问题更容易被发现。

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

  假设,主库A和备库B间的主备延迟是30分钟,这时候主库A停电了,HA系统要切换B作为主库。 img

  采用可靠性优先策略的话,就必须得等到备库B的seconds_behind_master=0之后,才能切换。但现在的情况比刚刚更严重,并不是系统只读、不可写的问题了,而是系统处于完全不可用的状态。

能否直接切换到备库B,但是保持B只读?   不行。因为,这段时间内,中转日志还没有应用完成,如果直接发起主备切换,客户端查询看不到之前执行完成的事务,会认为有数据丢失。

  所以说,MySQL高可用系统的可用性,是依赖于主备延迟的。延迟的时间越小,在主库故障的时候,服务恢复需要的时间就越短,可用性就越高。

  一般现在的数据库运维系统都有备库延迟监控,其实就是在备库上执行 show slave status,采集seconds_behind_master的值。如果有一个备库,它的延迟监控的图像类似下图: img

  备库的同步在这段时间完全被堵住了。产生这种现象典型的场景主要包括两种:

  1. 大事务(包括大表DDL、一个事务操作很多行);
  2. 备库起了一个长事务,如
begin; 
select * from t limit 1;

  然后就不动了。这时主库对表 t 做了一个加字段操作,这个DDL在备库应用的时候会被堵住。

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://wangjiawei.blog.csdn.net/article/details/113446280
-- 展开阅读全文 --
安全面试之XSS(跨站脚本攻击)
« 上一篇 07-24

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复