MySQL 高可用性知识总结

mgs2002 2020年07月20日 50次浏览

本篇文章是对《MySQL45讲》相关章节的简单总结。

原文地址:MySQL是怎么保证高可用的?

主备切换

MySQL实现高可用的基础就是主备切换,如图:
MySQL主备切换流程.jpg
主备切换可能是主动的,比如软件升级、数据备份、主库按计划下线等等,也可能是被动的,比如主库出现故障或者断电等。

主备延迟

主备切换肯定是有延迟的,同一个事务在备库执行完成的时候减去在主库完成时间的差值就是主备延迟(seconds_behind_master

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

seconds_behind_master的计算方式:

  1. 主库上面每个事务的binlog记录了一个时间字段,用于记录事务在主库的写入时间。
  2. 当该事务的binlog发送到备库执行时,备库会取出这个时间,并与当前系统时间进行差值计算得到seconds_behind_master,如下图。

主备延迟.jpg
正常网络情况下,主库binlog传给备库的时间是非常短的,也就是说主备延迟主要消耗就是备库接受binlog和执行完里面事务操作的时间差

所以说,主备延迟最直接的表现是,备库消费中转日志(relay log)的速度,比主库生产 binlog 的速度要慢。

来源

一、备库的机器比主库机器性能差
现在的项目环境下主备切换比较频繁,所以备库性能差的话必然导致主备延迟大,解决方案就是对称部署主库机器和备库机器配置和数据库参数配置保持一致

二、备库压力过大
备库一般用于查询数据或者执行一些不影响业务的数据分析,当查询过多的时候会耗费大量的CPU资源,影响了主备数据同步速度,导致主备延迟大。
这种情况一般处理方案有:

  • 一主多从。多配置几个从库分担读数据的压力。
  • 将binlog输出到外部系统,比如Hadoop。

一般会使用第一种方案。

三、大事务
大事务就是事务执行时间过长的事务,比如一次性删除的数据过多。因为主库上必须等事务执行完成才会写入 binlog,再传给备库。所以,如果一个主库上的语句执行 10 分钟,那这个事务很可能就会导致从库延迟 10 分钟。

另外一种大事务的场景就是大表的DDL(大表数据字段、索引的增删修改)。
这种情况可以使用gh-ost来进行online DDL,具体实践可参考这篇文章:gh-ost 在线 ddl 变更工具

四、备库的并行复制能力差异
待补充。。。。

主备切换策略

可靠性优先策略

MySQL主备切换策略可靠性优先.jpg
上图描述了可靠性优先策略的基本过程,可以看出在第二步的时候主库和备库的状态都为只读(readonly),一直持续到第5步才恢复正常。

如果主备库延迟时间很长(超过10分钟),那就意味着这段时间系统会一直处于不可用的问题,对于一般系统来说是不可接受的。

可用性优先策略

可靠性优先策略关注的是数据可用性,所以会判断主备延迟时间(SBM)来判断何时切换主备库。而可用性优先策略关注的是系统可用性,不会等到主备数据同步完成就会直接切换主备,所以几乎没有延迟时间。
MySQL主备切换策略可用性优先.png
因为可用性优先策略不会等待数据同步完成,所以由此引出一个问题:数据一致性
下图是可用性优先策略,且binlog_format=mixed的情况:
可用性优先策略,且 binlog_format=mixed.png
从上图可用看出,在第三步的时候因为主备有5秒的延迟,所以备库还没来得及执行c=4的插入语句时就接受了c=5的插入请求并入库(4,5),然后将对应binlog发给主库,主库接收到备库的c=4的请求后入库(5,4),从而导致两边数据不一致。
那如果将binlog_format设置为row会发生什么情况呢?
因为row格式记录的是新插入的字段所有值,所以只会有一行数据不一致。也就是说只会执行到备库的(4,5)和主库的(4,4),后面执行会报duplicate key error的错误并停止执行。
可用性优先策略,且 binlog_format=row.png
由此可以得出一些结论:

  • binlog_format设置为row可以更快的发现数据不一致,使用其他格式可能很久才会发现问题,很可能这时的数据不一致已经不可查,或者连带造成了更多的数据逻辑不一致。
  • 大多数情况下还是建议使用可靠性优先策略。因为对于一般的数据服务来说,数据的可靠性优先级大于可用性。
  • 在满足数据可靠性的前提下,MySQL 高可用系统的可用性,是依赖于主备延迟的。延迟的时间越小,在主库故障的时候,服务恢复需要的时间就越短,可用性就越高。