注册
登录
| 关键词： queries slow 但是 时间 问题 数据 监控 日志 status |
今天和同事处理了一个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得很好了，但是还是可能有其他环节会严重影响到你，真可谓：人在公司忙，锅从天上来。 要修复这个问题，也相对比较简单，我提取了近几天的服务变更情况，就很快缩小了范围，很快定位到了这台服务器。 |
| 本文出处： https://www.toutiao.com/a6780809955961209352/ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
