安基网 欢乐生肖 系统 数据库 查看内容

一个诡异的MySQL慢日志问题

2020-1-13 09:15| 投稿: |来自:


免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

摘要: 这是学习笔记的第 2186篇文章读完需要分钟速读仅需1分钟今天和同事处理了一个MySQL慢日志的问题,从这两天开始频繁收到一些报警信息,但是查看数据库端却没有任何异常。经过了几轮排查,最后结果刷新我对于问题的理解。从产生这些报警开始,报警就一直非常频繁,频繁到我想尽快解决这个问题。最开始定 ...

今天和同事处理了一个MySQL慢日志的问题,从这两天开始频繁收到一些报警信息,但是查看数据库端却没有任何异常。

经过了几轮排查,最后结果刷新我对于问题的理解。

从产生这些报警开始,报警就一直非常频繁,频繁到我想尽快解决这个问题。

最开始定位问题的方向是有一些业务的SQL没有使用索引,但是执行时间很短,可能导致被判别为慢查询,可以通过修改参数 log_queries_not_using_indexes 进行调整。

调整之后从慢日志来看,已经几乎没有慢日志了,但是从监控来看梳理依旧很大,是3万多个。

以下是打开和关闭log_queries_not_using_indexes前后,这个环境中的慢日志数量统计,就算按照已有的评判标准,慢日志个数最多也不会超过100个,但是报警却显示是3万多个。

查看全局变量slow_queries的结果可以看到,这个环境中的全局变量值为30118

>show global status like '%slow%';

+---------------------+-------+

| Variable_name | Value |

+---------------------+-------+

| Slow_launch_threads | 0 |

| Slow_queries | 30118 |

+---------------------+-------+

2 rows in set (0.00 sec)

但是查看会话状态却发现这个值始终是0

>show status like '%slow%';

+---------------------+-------+

| Variable_name | Value |

+---------------------+-------+

| Slow_launch_threads | 0 |

| Slow_queries | 0 |

+---------------------+--

这个问题的瓶颈其实不在于show global status和 show status的差异,还是简单说下,show global status得到的是数据库启动以来的累计状态值,要得到某一个时间点的数据,那么就需要对上一次的状态进行对比,比如现在的全局状态是3000,而一个小时前是2000,那么在这一个小时内的增量就是1000,所以哪怕会话层存在局限性,但是show global status反复检查都是稳定不变,也足以说明这个问题的奇怪。

我甚至怀疑,是不是MySQL的一个bug导致了这种奇怪的抖动现象。

从这个业务来看,本身的访问频率其实是不高的,数据写入也不多。

所以排除了这个层面的原因之后,我开始关注于监控层面,我抓取了本机的监控层面的一些数据,发现监控层面是按照时间来提取数据,

类似:

时间1,slow_queries值 30000

时间2,slow_queries值 30000

从日志来看显然也是没有问题的,增量明显是0,就算有的话也应该是个位数的抖动,但是为什么监控系统会识别异常呢。

我们继续进行分析,突然同事提醒了一句说,是不是上传的数据IP存在异常,让我们恍然大悟,比如本机上传的监控数据是没错的,但是如果另外一个客户端也上传了监控数据,但是把客户端IP的信息写错了,在监控服务端是会收到两份上传的数据,就可能触发如下的逻辑:

时间1:服务器1,slow_queries值 30000

时间2:服务器2,slow_queries值 2

时间3:服务器1,slow_queries值 30000

时间4:服务器2,slow_queries值 1

这种情况下,在服务端来看就是慢日志的增量在30000->2->30000->1之间进行频繁的变换。

所以这个问题就充分说明尽管你已经做得很好了,但是还是可能有其他环节会严重影响到你,记的第 2186 篇文章

读完需要

2分钟

速读仅需1分钟

今天和同事处理了一个MySQL慢日志的问题,从这两天开始频繁收到一些报警信息,但是查看数据库端却没有任何异常。

经过了几轮排查,最后结果刷新我对于问题的理解。

从产生这些报警开始,报警就一直非常频繁,频繁到我想尽快解决这个问题。

最开始定位问题的方向是有一些业务的SQL没有使用索引,但是执行时间很短,可能导致被判别为慢查询,可以通过修改参数 log_queries_not_using_indexes 进行调整。

调整之后从慢日志来看,已经几乎没有慢日志了,但是从监控来看梳理依旧很大,是3万多个。

以下是打开和关闭log_queries_not_using_indexes前后,这个环境中的慢日志数量统计,就算按照已有的评判标准,慢日志个数最多也不会超过100个,但是报警却显示是3万多个。

查看全局变量slow_queries的结果可以看到,这个环境中的全局变量值为30118

>show global status like '%slow%';

+---------------------+-------+

| Variable_name | Value |

+---------------------+-------+

| Slow_launch_threads | 0 |

| Slow_queries | 30118 |

+---------------------+-------+

2 rows in set (0.00 sec)

但是查看会话状态却发现这个值始终是0

>show status like '%slow%';

+---------------------+-------+

| Variable_name | Value |

+---------------------+-------+

| Slow_launch_threads | 0 |

| Slow_queries | 0 |

+---------------------+--

这个问题的瓶颈其实不在于show global status和 show status的差异,还是简单说下,show global status得到的是数据库启动以来的累计状态值,要得到某一个时间点的数据,那么就需要对上一次的状态进行对比,比如现在的全局状态是3000,而一个小时前是2000,那么在这一个小时内的增量就是1000,所以哪怕会话层存在局限性,但是show global status反复检查都是稳定不变,也足以说明这个问题的奇怪。

我甚至怀疑,是不是MySQL的一个bug导致了这种奇怪的抖动现象。

从这个业务来看,本身的访问频率其实是不高的,数据写入也不多。

所以排除了这个层面的原因之后,我开始关注于监控层面,我抓取了本机的监控层面的一些数据,发现监控层面是按照时间来提取数据,

类似:

时间1,slow_queries值 30000

时间2,slow_queries值 30000

从日志来看显然也是没有问题的,增量明显是0,就算有的话也应该是个位数的抖动,但是为什么监控系统会识别异常呢。

我们继续进行分析,突然同事提醒了一句说,是不是上传的数据IP存在异常,让我们恍然大悟,比如本机上传的监控数据是没错的,但是如果另外一个客户端也上传了监控数据,但是把客户端IP的信息写错了,在监控服务端是会收到两份上传的数据,就可能触发如下的逻辑:

时间1:服务器1,slow_queries值 30000

时间2:服务器2,slow_queries值 2

时间3:服务器1,slow_queries值 30000

时间4:服务器2,slow_queries值 1

这种情况下,在服务端来看就是慢日志的增量在30000->2->30000->1之间进行频繁的变换。

所以这个问题就充分说明尽管你已经做zhen得很好了,但是还是可能有其他环节会严重影响到你,真可谓:人在公司忙,锅从天上来。

要修复这个问题,也相对比较简单,我提取了近几天的服务变更情况,就很快缩小了范围,很快定位到了这台服务器。



小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:https://www.toutiao.com/a6780809955961209352/

免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

相关阅读

最新评论

 最新
返回顶部
河北11选5走势图 上海时时乐 北京两步彩 欢乐生肖 幸运飞艇官网 秒速快3 欢乐生肖 德国时时彩 幸运赛车 上海时时乐开奖