MySQL令人头疼的Aborted告警案例分析

MySQL关于aborted告警日志的分析

实战

Part1:写在最前

在MySQL的error log中，我们会经常性看到一些各类的Aborted
connection错误，本文中会针对这类错误进行一个初步分析，并了解一个问题产生后的基本排查思路和方法。掌握这种方法是至关重要的，而不是出现问题了，去猜，去试。数据库出现问题的时候需要DBA在短时间内快速解决问题，因此一个好与坏的DBA，区别也在于此。

Part2:种类

Part3:重点参数分析

wait_timeout

这个参数指的是数据库系统在关闭它之前，服务器等待非交互式连接上的活动的秒数。

interactive_timeout

这个参数指的是在关闭交互式连接之前，服务器等待活动的秒数

Warning:警告这两个参数建议一起调节，能够避免一些坑。

本文的两个参数值采用的是默认值

另外在数据库中，我们重点关注下这两个参数，看看什么情况下Aborted_clients会提升，什么情况下Aborted_connects 会提升

Part4:案例1

这里我故意输入错误的密码5次，来看下数据库的error log和Aborted的哪个参数记载了这一问题

可以看出，这里的Aborted_connects 记录了密码错误的这一问题

error log中，也记载了这类密码输错的信息

Part5:案例2

接下来我们看下文章第三节提到的两个重点参数对数据库连接的行为影响

这里我们将这两个参数均配置为10秒

这里三次操作，可以看到clients数上升，这是由于timeout参数控制的，已经连接上数据的连接被杀掉。

error log中记载的是

Part6:案例3

在这个案例中我们看下最大连接数对数据库连接的行为影响

这里看到爆出了连接数过多的问题 

而错误日志没有任何记录

Part7:案例4

第三方工具navicat select结果没有出来的时候选择停止则出现

clients上涨

error log日志记录

Part8:原因总结

1. 在MySQL中sleep状态数百秒的而且经常重复连接是应用程序在工作后没有关闭连接的症状之一，而是依靠数据库wait_timeout来关闭它们。强烈建议在操作结束时更改应用程序逻辑以正确关闭连接；

2. 检查以确保max_allowed_packet的值足够高，并且客户端没有收到“数据包太大”消息。 这种情况他会中止连接，而不正确关闭它；

3. 另一种可能性是TIME_WAIT。建议您确认连接被妥善管理并且是在应用端正常关闭；

4. 确保事务正确提交（开始和提交），以便一旦应用程序“完成”连接，它将处于“clean”的状态；

5. 您应该确保客户端应用程序不中止连接。 例如，如果PHP的选项max_execution_time设置为5秒，增加connect_timeout是没用的，因为PHP会杀死脚本。 其他编程语言和环境也有类似的选项；

6. 连接延迟的另一个原因是DNS问题。 检查是否启用了skip-name-resolve，检查主机根据其IP地址而不是其主机名进行身份验证；

7. 尝试增加MySQL的net_read_timeout和net_write_timeout值，看看是否减少了错误的数量。

——总结——

通过这4个案例，我们能够了解到，Aborted_clients、和Aborted_connects的区别，以及什么情况下会爆出什么样的错误日志，文章第二节中的几个Aborted错误是常见的错误，这类错误出现的时候脑海里要有一个理论知识，知道什么情况下，会出现什么样的错误，以便快速定位问题。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。

喜欢的读者可以点个赞来个关注，您的赞美和关注是对笔者继续发文的最大鼓励与支持！

• 
  
  打赏
  
• 
  
  10赞
  
• 
  
  3收藏
  
• 
  
  评论
  
• 
  
  举报