Mysql主从架构

一致性：

• 最终一致性：时效性要求不高，在一定时间内达到一致即可
• 强一致性：时效性要求严格

提要

正常情况下，只要主库更新生成的 bin log，都能传到备库且正确执行，备库就能达到跟主库一致的状态，这就是最终一致性。但是，Mysql 要提供高可用能力，只有最终一致性是不够的，今天我们就来聊聊这个问题。

这里再放一下，上一篇文章中的双 M 机构的主备切换流程图。

主备延迟

主备切换可能是主动运维的动作，比如，软件升级、主库所在机器计划下线等等，也有可能是被动操作，比如主库所在机器掉电等。
在介绍主动切换流程前，先说明一个概念“同步延迟”：

1. 主库 A 完成一个事务，写bin log，这个时刻记为 T1；
2. 之后传给备库 B，B收到bin log 时刻记为 T2；
3. 备库B 解析并执行完这个事务，这个时刻记为 T3。

所谓主备延迟，指的是同一个事务，在备库执行完成时间与在主库执行完成时间的差值，也就是T3-T1。

你可以在备库上执行 show slave status 命令，通过返回结果的 seconds_behind_master 查看当前备库与主库延迟了多少秒，精度为秒。seconds_behind_master 的计算方法是这样的：

1. 每个事务的 bin log 里，都会记录这个事务在主库上写入的时间；
2. 备库取出这个时间，跟自己当前系统时间计算差值，得到 seconds_behind_master 。
   说明：如果主库和备库的系统时间不一致，备库在连接到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数获取主库的系统时间，如果不一致，备库在计算 seconds_behind_master 的时候会扣掉这个差值。

在网络正常的时候，binlog 在传给备库的时间是很短的，这种情况下，主备延迟的主要来源就是备库接收完bin log 和执行完这个事务的时间差。

主备延迟的来源

一、 非对称部署，就是说备库所在的机器性能要比主库所在机器的性能差。

二、即使对称部署，在备库压力大时，也会出现主备延迟。对于主库，由于会影响业务，大家用起来比较克制，从而忽视了备库的压力控制。结果就是备库上的查询耗费了大量的cpu资源，影响了同步速度，造成主备延迟。这种情况，一般可以这么处理：

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

一般会采用一主多从的方式，因为数据系统还必须保证有定期的全量备份。而从库就很适合用来做备份。

三、大事务
这种情况很好理解，只有等到主库上的事务执行完成才会写入 bin log，再传给备库。所以，如果一个在主库上执行了10分钟的语句，那么这个事务很可能会导致从库延迟10分钟。尽量减少大事务，如：一次性delete 掉太多数据。

四、备库的复制能力，下一篇文章展开讨论。

主备切换策略

一、可靠性优先策略
在双M架构下，从状态1切换到状态2的流程如下：

1. 在备库上查看 seconds_behind_master ，如果小于某个值（比如5秒）继续下一步，否则持续重试第一步；
2. 这里 seconds_behind_master 已经小于我们预期的值了，把主库改为只读状态；
3. 判断备库的 seconds_behind_master 是否为 0，直到为 0 为止；
4. 把备库 B 改为可读写状态；
5. 把业务请求切到备库 B。

细心的同学可能意识到了，这种策略有一段时间的服务不可用，也就是等 seconds_behind_master 为0 的这段时间。所以，在第一步就需要保证 seconds_behind_master 足够小，尽量减少不可用时间。

二、可用性优先策略
也就是说，强行把步骤4、5 提到最开始执行，也就是说不等主备一致，直接切换。结果就是主备数据可能不一致

总结

在满足数据可靠性的前提下，数据库的高可用性，是依赖于主备延迟的。延迟越小，在主库故障的时候，切换的时间就越短，可用性就越高。

推荐一个零声学院免费教程，个人觉得老师讲得不错，
分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，
fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，
TCP/IP，协程，DPDK等技术内容，点击立即学习: