Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

25 | MySQL是怎么保证高可用的? #36

Open
git-zjx opened this issue Sep 18, 2019 · 0 comments

Comments

@git-zjx
Copy link
Owner

commented Sep 18, 2019

在满足数据可靠性的前提下,MySQL 高可用系统的可用性,是依赖于主备延迟的。延迟的时间越小,在主库故障的时候,服务恢复需要的时间就越短,可用性就越高
主备延迟
数据同步有关的时间点主要包括以下三个:

  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

网络正常情况下,主备延迟的主要来源是备库接收完 binlog 和执行完这个事务之间的时间差。所以说,主备延迟最直接的表现是,备库消费中转日志(relay log)的速度,比主库生产 binlog 的速度要慢

主备延迟的原因

  1. 备库所在机器的性能比主库所在的机器性能差
    实际上,更新过程中也会触发大量的读操作。所以,当备库主机上的多个备库都在争抢资源的时候,就可能会导致主备延迟了。
    因为主备可能发生切换,备库随时可能变成主库,所以主备库选用相同规格的机器,并且做对称部署,是现在比较常见的情况
  2. 备库的压力大
    一般的想法是,主库既然提供了写能力,那么备库可以提供一些读能力。或者一些运营后台需要的分析语句,不能影响正常业务,所以只能在备库上跑。
    由于主库直接影响业务,所以使用会比较克制,忽视了备库的压力控制,备库上的查询耗费了大量的 CPU 资源,影响了同步速度,造成主备延迟
    可以通过以下方式解决:
  • 一主多从。除了备库外,可以多接几个从库,让这些从库来分担读的压力
  • 通过 binlog 输出到外部系统,比如 Hadoop 这类系统,让外部系统提供统计类查询的能力
  1. 大事务
    因为主库上必须等事务执行完成才会写入 binlog,再传给备库。所以,如果一个主库上的语句执行 10 分钟,那这个事务很可能就会导致从库延迟 10 分钟
    避免大事务的方式:
  • 不要一次性地用 delete 语句删除太多数据
  • 大表 DDL,计划内的 DDL,建议使用 gh-ost 方案
  1. 备库的并行复制能力-见下节

主备切换策略

  1. 可靠性优先策略
    双 M 结构下,从主备切换的详细过程:
    Ⅰ. 判断备库 B 现在的 seconds_behind_master,如果小于某个值(比如 5 秒)继续下一步,否则持续重试这一步
    Ⅱ. 把主库 A 改成只读状态,即把 readonly 设置为 true;
    Ⅲ. 判断备库 B 的 seconds_behind_master 的值,直到这个值变成 0 为止;
    Ⅳ. 把备库 B 改成可读写状态,也就是把 readonly 设置为 false;
    Ⅴ. 把业务请求切到备库 B。
    54f4c7c31e6f0f807c2ab77f78c8844a
    步骤 Ⅱ 到步骤 Ⅴ 之间系统处于不可写状态,其中比较耗时的是步骤 Ⅲ,这也是为什么需要在步骤 1 先做判断,确保 seconds_behind_master 的值足够小
  2. 可用性优先策略
    不等主备数据同步,直接把连接切到备库 B,并且让备库 B 可以读写,那么系统几乎就没有不可用时间,这个切换流程的代价,就是可能出现数据不一致的情况
    可用性优先策略,且 binlog_format=mixed时的切换流程和数据结果:
    3786bd6ad37faa34aca25bf1a1d8af3a
    可用性优先策略,且 binlog_format=row时的切换流程和数据结果:
    b8d2229b2b40dd087fd3b111d1bdda43
    因为 row 格式在记录 binlog 的时候,会记录新插入的行的所有字段值,所以最后只会有一行不一致。而且,两边的主备同步的应用线程会报错 duplicate key error 并停止
    由此可知:
  • 使用 row 格式的 binlog 时,数据不一致的问题更容易被发现。而使用 mixed 或者 statement 格式的 binlog 时,数据很可能悄悄地就不一致了。如果你过了很久才发现数据不一致的问题,很可能这时的数据不一致已经不可查,或者连带造成了更多的数据逻辑不一致。
  • 主备切换的可用性优先策略会导致数据不一致。因此,大多数情况下,我都建议你使用可靠性优先策略。毕竟对数据服务来说的话,数据的可靠性一般还是要优于可用性的
@git-zjx git-zjx added this to MySQL实战45讲 in MySQL Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
MySQL
MySQL实战45讲
1 participant
You can’t perform that action at this time.