MySQL从库卡主了--读写分离也不能乱读

不少使用数据库的公司，数据库都建立主从。无论Oracle、MySQL还是PostgreSQL都会有这类应用。而TiDB这种分布式数据本身是一套高可用。当然我刚才提到的Oracle、MySQL还是PostgreSQL也早就有了自己的分布式。我们今天还是说主从的这种架构。一般主从可以起到硬件故障的灾备，但是现在的硬件情况，很少硬件损坏。大家用从库做读写分离或者说分析的也很多。（如果说现在谁家的硬件天天坏，天天进行灾备切换实操的）

     今天说一个故事，我的一个学员问我她们遇到的问题：上来给我一张图。我看到这个描述第一次见。只能说明踩坑还不够。然后看到她图中主从差了28000多秒。我说这种情况基本上指望同步恢复不现实了。（以我以前经验这话还能追回来的概率不大，不过最后结果还是反转的）

然后她不经意间截图了这个。我看到了“ invalidating query cache entries ”那么说明从库在刷缓存的时候卡主了。我开始以为是insert没提交。不过实际情况是她一主三从的数据库上，一主和两个从上都是好的，已经插入了。那么就排除了各种我能想到的问题。只有一种可能了，有人在这个库上执行大查询，导致内存竞争，卡主了。事务提交不下去。

     随机让她检查这个从库上有没有大查询。一查果然有。 那么结果就是杀掉这几个大查询，或者把从库重启一下。最终采用了kill会话的操作，解决了。那几个杀掉的我这里就不贴了。大致是select distinct x,y,z.......... from t     重点是没有where条件。而且是不止一个会话这样执行，然后就没有然后了。对于这样全表遍历且排序的并发执行，我见过几次这种都造成故障了（当时是主库）。这个由于是人为查询的从库，估计现场没有造成影响，但是确实是问题。

     主从产生延迟的几种可能性

1、主大事务从在等 2、从串行执行忙不过来 3、从执行的事务阻塞了主的同步事务

    有时候不能因为是从库，就可以无节操的查询，比如全量操作数据，也是有可能把从库搞瘫痪的。