初学MySQL——高可用性

先看一下双M结构的主备切换流程图：

主备延迟

先了解一下“同步延迟”的概念：

1. 主库A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
2. 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
3. 备库 B 执行完成这个事务，我们把这个时刻记为 T3；

所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之差，T3-T1;

采用show slave status;命令，返回结果中的seconds_behind_master,用于表示当前备库延迟了多少秒；

网络情况正常下，日志从主库传给备库的时间是很短的，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。

主备延迟来源

在有些部署条件下，备库所在的机器的性能要比主库所在的机器性能要差
这种情况现在很少部署了，因为主备可能发生切换，备库随时可以变成主库，所以主备库选用相同规格的机器，并且做对称部署；

第二种是备库压力大
由于主库直接影响业务，反而忽视了备库的压力控制，结果就是备库上的查询耗费了大量的CPU资源，影响了同步的速度，造成主备延迟；

1. 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力；
2. 通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力；

一主多从的方式大都会被采用，作为数据库系统，必须保证有定期全量备份的能力，从库就很适合用来做备份；

大事务也会造成主备延迟
主库上必须等事务执行完成之后才会写入binlog,再传给备库，如果主库上的语句执行10分钟，那么事务可能会导致从库延迟10分钟；

例子：不要一次用delete语句删除太多数据，典型的大事务场景；这就需要避免在高峰期操作，控制每个事务的删除量，分成多次删除；

另一种典型的大事务场景，就是大表DDL

可靠性优先策略

在开篇图中的双M结构，从状态1切换到状态2的详细过程如下：

1. 先判断备库B现在的SBM(seconds_behind_master)如果小于某个值继续下一步，否则持续重试这一步；
2. 把主库状态改为readonly,设置为true;
3. 判断备库 B 的 SBM 的值，直到这个值变成 0 为止；
4. 把备库 B 改成可读写状态，也就是把 readonly 设置为 false;
5. 把业务请求切到备库 B;
   
   系统的不可用时间，是由数据可靠性优先的策略决定的，可以选择可用性优先的策略来把这个不可用时间降为0；

可用性优先策略

如果强行把步骤4、5调整到最开始执行，不等主备数据同步，直接把连接切换到备库B,并且让备库B可以读写，系统几乎没有不可用时间，但是代价就是可能会出现数据不一致的情况；

总结

MySQL高可用的基础就是主备切换逻辑，讨论了主备延迟的情况以及相应的改进方向；

由于主备延迟的存在，切换策略会有不同的选择，需要一起分析可靠性优先和可用性优先策略的区别；

在实际应用中，建议使用可靠性优先的策略，保证数据准确，这是数据库服务的底线；
通过减少主备延迟，提升系统的可用性；