Mysql主从延时
前言
很多公司都采用的Mysql主从架构,相信很多人困扰于主从延时问题,这篇文章就系统的讲述下Mysql主从延时问题。
- Mysql主从同步原理
- Mysql主从延时解决方案
- Mysql主从延时过长
Mysql主从同步原理
从Canal官网抄个图
![](http://upload-images.jianshu.io/upload_images/8422585-28d28d999f93685e.png?imageMogr2/auto-orient/strip|imageView2/2/w/539/format/webp)
主从同步.png
大致流程如下:
![](http://upload-images.jianshu.io/upload_images/8422585-f15e81a746c4b9f2.jpg?imageMogr2/auto-orient/strip|imageView2/2/w/584/format/webp)
mysql-主从流程.jpg
可以看出从master接到一个写请求到数据回放到从库的时间为T1+T2+T3,
主从延时的时间为T2+T3。一般来说这部分时间为200ms左右,这部分延时是无法避免的。这就导致一些写入立即读的场景可能得不到刚才变化的结果。比如,商家发布商品成功后,如果立即跳到已发布商品页,可能会查不到刚刚发布的商品。
这时商家可能会有很多问号。
Mysql主从延时解决方案
这种问题解决方案有三种:
- 产品交互做调整,在写请求后读操作前,加入一些拖时间的交互,以保证数据已经同步到从库。比如,商家发布商品后,弹出一个弹框(继续发布商品 or 去已发布商品页)。
- 强制读主库。这种方案看起来很low,但是我相信大部分公司都采用的这种方案,原因也很直白:简单呀!采用了这种方案也就意味着抛弃了从库的读扩展性。
-
选择性读主库。
mysql选择性读主.jpg
棒!
Mysql主从延时过长
接下来,我们来分析主从同步延时时长远超预期的原因。我们知道主从延时时间T=T2+T3。网络延迟会导致T2过长,这种情况比较少,而且不是我们讨论的重点,就一笔带过了。实际上我们遇到的大多数情况是T3过长。T3耗时主要在Relay log回放数据这一步。可能原因如下:
1. 从库机器配置比主库低
从库的压力其实比主库更大。因为从库除了执行主库执行的全部写操作外,还要处理读请求。
- 从库读压力过大
如果机器配置一样,主从延时还是过长,那么有可能是从库读压力过大,占用过多服务器资源。可以增加从库分担压力。 - 大事务
这个也很好理解,一个事务在主库需要执行五分钟的话,在从库回放时也需要五分钟。延时也就会增加五分钟。 - 存在长时间持有exclusive metadata lock的操作
最典型的就是大表DDL。大表DDL一般耗时较长,执行期间会阻塞读请求。
关于大表DDL参考我的另一篇文章数据库扩展