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

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

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

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

- 流程图

-

二：什么是同步延迟？

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

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

- 主库 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 模式，使得不一致错误更容易发现 )

- 优点

- 无不可用时间。

- 策略选择？

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

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

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