mysql如何保证高可用？
正常情况下，只要主库执行更新生成的所有binlog,都可以被传到备库并被正确的执行
备库就能达到和主库一致的状态，这就是最终一致性
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
主备延迟只要时间段是T3 – T2,也就是执行relayLog的时间，因为把binlog从网络中传输是很快的
产生主备延迟的原因
- 备库所在机器性能要比主库差
- 备库所在机器性能要比主库差的话，主库执行10分钟，备库执行30分钟，累计几个月，延迟时间就是天文数字了
- 开发人员忽视了备库上的压力，对备库进行大量的压力测试，导致备库争抢资源吃力
- 有的时候备库上会有大量的查询，查询会消耗大量的CPU资源，从而导致从主库上传过来的Binlog很难抢到CPU资源执行relayLog
- 大事务
- 如果一个大事务在主库上要执行30分钟，在备库上就得执行三十分钟，就堵住其他事务三十分钟
处理主备延迟的两种策略
可靠性优先
- 发起主备切换时，主库先判断备库的seconds_behind_master是否小于5秒，如果小于5秒，就执行下一步，否则就重复执行这一步
- 设置主库的readOnly=true,也就是把主库设置为只读状态
- 判断备库B的seconds_behind_master是否为0，如果为0的话就执行下一步，否则等待值为0
- 设置从库的readOnly=false，也就是设置从库为可读写状态
- 将业务请求切到备库B
可用性优先
可靠性优先相比，可用性优先直接执行可靠性优先的4,5步骤，忽略1,2,3步骤，也就是直接把备库切换成主库，把之前的未执行语句给放在一边
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/202534.html
