MySQL深入——16

发布时间:2024年01月24日

MySQL如何保持高可用??

主备延迟

主备延迟分为两类,一类主动比如软件升级,主库所在机器按照计划下线等,另外一类是被动,比如主库所在机器掉电。

在看这个概念之前,我们先来看看“同步延迟”,与数据同步有关的时间点有三个

1.主库A完成事务,写入binlog,这是T1时刻

2.主库A将binlog发送给备库B,B接收完毕,这是T2时刻

3. 备库B执行完成这个事务,这是时刻T3。

所谓的主备延迟就是T3-T1的差值。

可以使用show slave status命令来看seconds_behind_master来看看备库延迟了多少秒。

因为在每个事务的binlog当中都有一个时间字段来记录主库写入的时间,备库他会将正在执行事务的时间字段与当前系统的时间做差,得到延迟时间。

那么我们可能会想,既然是与备库的系统时间作差实现的,那么有没有可能备库的系统时间与主库的系统时间不同,从而导致延迟时间不准呢?其实这是不必担心的,在备库连接到主库的时候,他会通过一个select unix_timestamp()函数来获得主库的系统时间,要是发现与自己的不同,他会在计算的时候直接扣除这个时间差。

主备延迟最直接的表现是,备库消费中转日志(relay log)的速度,比主库生产binlog的速度要慢,这是什么导致的呢?

主备延迟的来源

首先在有些情况下,备库的机器性能是比主库的机器性能要差的。

或者备库的压力太大,因为大多数情况下,因为主库提供了写能力,那么备库就提供一些读能力,或者一些分析语句,因为主库是直接影响业务的,所以全在备库上运行导致压力过大,耗费了大量的CPU资源从而影响了同步速度,造成了主备延迟。

要解决这种问题,我们可以多接几个从库,让从库来分担压力,或者通过binlog输出到外部系统,比如Hadoop这类系统,让外部系统提供查询的功能。

还有一种可能就是大事务造成的,因为主库上必须得等事务执行完了之后才会写入binlog,假如他执行了10分钟,就会导致10分钟的主备延迟。

可靠性优先策略

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

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

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

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

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

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

如果一开始主备延迟就长达 30 分钟,而不先做判断直接切换的话,系统的不可用时间就长达30分钟。

可用性优先策略

如果我强行将步骤4.5放到刚开始就执行,就是说不用等主备数据同步,直接将连接切换到备库B上,让备库可以读写,那么系统就没有不可用时间了。这样操作的代价是可能出现数据不一致的情况。

在紧急情况下,比如主库掉电,就不能使用可靠性优先策略,因为要等待seconds_behind_master为0,直接使用可用性优先策略,进行切换,事后再补数据。

文章来源:https://blog.csdn.net/Cobrander2_0/article/details/135820679
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。