生产问题（六）Mysql主从同步延迟

一、引言

        线上这几天早上都有业务操作完之后查不到数据的问题，一开始还以为是校验调用了其他单据位置啥的校验，后来拿着sql到主库和从库一查，从库没有数据，延迟了一个多小时。

二、排查

        线上使用的是Mysql5.7，半同步模式，跟dba沟通的时候，一开始还以为同步模式是这样，然后备库每天凌晨的物理备份需要四个小时，当主库有ddl的时候，备库卡住了，系统读从库没有读到数据。

        这里产生了几个疑问：①备库拿来做高可用怎么会只有每天凌晨备份一次，不应该是实时同步吗？

        ②主库有ddl，既然还能响应系统写入，说明binlog数据还在更新，从库通过binlog进行同步，为什么没有数据？

         然后再聊了一下，实际的架构是下面这样：

         主库2作为高可用的准备，实时同步主库，在主库宕机的时候会成为主库，平时在凌晨还会生成物理备份文件，用于数据有问题时恢复到前一天。

        虽然开启了log_slave_update，从库也会记录binlog，可以做级联同步，但是实际上延迟会比较大，dba还是设置都拉取主库 。从库的binlog可以给数据仓库、Flink之类的工具进行同步。

        主库2也作为读的一部分，实际延时的原因是：系统读数据时，读的域名漂移到了主库2，主库2在做物理备份，当备份卡住的时候，数据更新被阻塞。

三、解决

        解决方式有多种：

        1、将主库2排除作为读查询，这个暂时不打算，后期如果还有问题在考虑，毕竟万一三个从库都挂了呢？

        2、设置主库2进行物理备份的阻塞时间，超过一定时间的阻塞就停止此次备份，过一会从头开始，这个做法dba觉得更好，博主认为是有隐患的，容易导致备份的不断循环。

        3、结合物理备份与LVM逻辑备份，物理备份一周备份一次就行，每天使用LVM逻辑备份，这也是博主看的《高性能Mysql》推荐的做法，结合2基本不会有问题。但是这需要运维开发备份管理自动化，dba感觉没必要。

四、总结

        这里涉及到Mysql同步、备份相关的基础知识，博主懒得写，有兴趣的同学可以看看《高性能Mysql》

        不同的架构产生的问题，对应的优化解决方案不同，有兴趣可以互相交流