前言
很多公司都采用的Mysql主从架构，相信很多人困扰于主从延时问题，这篇文章就系统的讲述下Mysql主从延时问题。
- Mysql主从同步原理
- Mysql主从延时解决方案
- Mysql主从延时过长
Mysql主从同步原理
从Canal官网抄个图
主从同步.png
大致流程如下：
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参考我的另一篇文章数据库扩展
