MySQL 是怎么保证高可用的？

最新推荐文章于 2024-03-13 13:00:32 发布

发飙的蜗牛咻咻咻~

最新推荐文章于 2024-03-13 13:00:32 发布

阅读量396

点赞数 2

分类专栏： ★ MySQL 实战文章标签：主备延迟高可用可靠性优先策略可用性优先策略

huadong

本文链接：https://blog.csdn.net/qq_36221788/article/details/103461617

版权

24 篇文章 1 订阅

订阅专栏

在一个主备关系中，每个备库接收主库的 binlog 并执行。正常情况下，只要主库执行更新生成的所有 binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。MySQL 要提供高可用能力，只有最终一致性是不够的。为什么这么说呢？今天就着重来分析一下。

主备延迟

与数据同步有关的时间点主要包括以下三个：
- 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1；
- 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2；
- 备库 B 执行完成这个事务，我们把这个时刻记为 T3。
主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
可以在备库上执行show slave status命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

有些部署条件下，备库所在机器的性能要比主库所在的机器性能差。
- 一般情况下，有人这么部署时的想法是，反正备库没有请求，所以可以用差一点儿的机器。或者，他们会把 20 个主库放在 4 台机器上，而把备库集中在一台机器上。
第二种常见的可能是备库的压力大。
- 这种情况的想法是，主库既然提供了写能力，那么备库可以提供一些读能力，或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。
- 由于主库直接影响业务，大家使用起来会比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。
- 这种情况，一般可以这么处理：
  - 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
  - 通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。
还有第三种可能，可能存在大事务。
- 大事务这种情况很好理解，因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟。

由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。

如果强行把可靠性优先策略的步骤 4、5 调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库 B，并且让备库 B 可以读写，那么系统几乎就没有不可用时间了。
我们把这个切换流程，暂时称作可用性优先流程。这个切换流程的代价，就是可能出现数据不一致的情况。

笔记来源于《极客时间：MySQL实战45讲：MySQL是怎么保证高可用的？》

关注