mysql的高可用

正常情况下，只要主库执行更新生成的所有binlog,都可以被传到备库并被正确的执行
备库就能达到和主库一致的状态，这就是最终一致性
mysql要提供高可用能力，只有最终一致性是不够的

主备延迟

• 主备切换可能是一个主动运维动作，比如软件升级，主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电

主动切换的场景

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

主备延迟: 就是同一个事务，在备库执行完成的时间和主库执行完成的时间的差值，也就是T3 - T1

查看延迟时间的语句：show slave status,返回结果会显示seconds_behind_master，用于表示当前备库延迟了多少秒

seconds_behind_master的计算方法

1. 每个事务的Binlog里面都有一个时间字段，用于记录主库上写入的时间
2. 备库取出当前正在执行的事务的时间字段的值，计算他与当前系统时间的差值，得到seconds_behind_master

主备延迟只要时间段是T3 - T2,也就是执行relayLog的时间，因为把binlog从网络中传输是很快的

产生主备延迟的原因

• 备库所在机器性能要比主库差
  • 备库所在机器性能要比主库差的话，主库执行10分钟，备库执行30分钟，累计几个月，延迟时间就是天文数字了
• 开发人员忽视了备库上的压力，对备库进行大量的压力测试，导致备库争抢资源吃力
  • 有的时候备库上会有大量的查询，查询会消耗大量的CPU资源，从而导致从主库上传过来的Binlog很难抢到CPU资源执行relayLog
• 大事务
  • 如果一个大事务在主库上要执行30分钟，在备库上就得执行三十分钟，就堵住其他事务三十分钟

处理主备延迟的两种策略

可靠性优先

1. 发起主备切换时，主库先判断备库的seconds_behind_master是否小于5秒，如果小于5秒，就执行下一步，否则就重复执行这一步
2. 设置主库的readOnly=true,也就是把主库设置为只读状态
3. 判断备库B的seconds_behind_master是否为0，如果为0的话就执行下一步，否则等待值为0
4. 设置从库的readOnly=false，也就是设置从库为可读写状态
5. 将业务请求切到备库B

可用性优先

可靠性优先相比，可用性优先直接执行可靠性优先的4,5步骤，忽略1,2,3步骤，也就是直接把备库切换成主库，把之前的未执行语句给放在一边