《Mysql - Mysql 是如何保证高可用的？》

Posted 2022-01-21 25-lh

一：为什么要进行主备切换？ 

　　- 比如软件升级、主库所在机器按计划下线等。主动运维。

　　- 比如主库所在机器掉电,为了保证服务的正常运行，而进行切换。可能是被动操作。

　　- 流程图

　　-  

 

二：什么是同步延迟？

　　- 在介绍主动切换流程的详细步骤之前，先跟你说明一个概念，既“同步延迟”

　　- 与数据同步有关的时间点主要包括以下三个：

　　　　- 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;

　　　　- 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;

　　　　- 备库 B 执行完成这个事务，我们把这个时刻记为 T3。 

 

二：什么是主备延迟？

　　- 所谓主备延迟，就是在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。 

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

　　- seconds_behind_master 计算规则

　　　　- 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间。

　　　　- 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。

　　- 需要说明的是，在网络正常的时候，日志从主库传给备库所需的时间是很短的，即 T2-T1 的值是非常小的。

　　- 所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度（T2-T3 之间） ，比主库生产 binlog 的速度要慢。

 

三：什么情况会导致主备延迟？

　　- (主 / 从) (机器不同 / 配置不同)（不常见） 

　　　　- 当备库所在机器性能较差/mysql配置不同，备库争抢资源/配置问题，就可能会导致主备延迟了。

 

　　- 备库压力过大

　　　　- 备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。

　　　　- 解决

　　　　　　-  一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。

　　　　　　-  通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。

 

　　- 大事务 / 大表 DDL 

　　　　- 因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以当有大事务的进行，会导致延迟。

　　　　- 例如： 不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。

 

　　- 其他

　　　　- 主库 DML 并发大，从库 QPS 高。

　　　　- 从库备份。

 

四：如何主备切换？

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

　　

　　- 可靠性优先策略

　　　　- 流程（在图 1 的双 M 结构下）( 一般是由专门的 HA（双机集群系统） 来完成)

　　　　　　- 判断备库 B 现在的 seconds_behind_master，如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；

　　　　　　- 把主库 A 改成只读状态，即把 readonly 设置为 true；

　　　　　　- 判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；

　　　　　　- 把备库 B 改成可读写状态，也就是把 readonly 设置为 false；

　　　　　　- 把业务请求切到备库 B。 

　　　　- 问题

　　　　　　- 可以看到，这个切换流程中是有不可用时间的。

　　　　　　- 因为在步骤 2 之后，主库 A 和备库 B 都处于 readonly 状态，也就是说这时系统处于不可写状态，直到步骤 5 完成后才能恢复。

　　　　- 总结

　　　　　　- 在确定使用可用性优先策略时候，先做判断，确保 seconds_behind_master 的值足够小。这样可以保证切换够快。

　　　　　　- 试想如果一开始主备延迟就长达 30 分钟，而不先做判断直接切换的话，系统的不可用时间就会长达 30 分钟，这种情况一般业务都是不可接受的。

　　　　- 优点

　　　　　　- 数据可靠。无需修复数据。

　　　　

　　- 可用性优先策略

　　　　- 流程（在图 1 的双 M 结构下）

　　　　　　- 不检查 seconds_behind_master，直接进行上面 4,5 步的主从切换。

　　　　- 问题

　　　　　　- 这个切换流程的代价，就是可能出现数据不一致的情况。(binglog 推荐使用 row 模式，使得不一致错误更容易发现 )

　　　　- 优点

　　　　　　- 无不可用时间。

 

　　- 策略选择？

　　　　- 更多的从业务上去考虑。

　　　　- 如过这个业务已经是不可用的状态，那么也只能选择可用优先。

　　　　- 如果这个业务是正常的切换，那么就应该选择可靠优先策略。