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

MySQL关于aborted告警日志的分析

实战

Part1:写在最前

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

Part2:种类

[Warning] Aborted connection 305628 to db: ‘db‘ user: ‘dbuser‘ host: ‘hostname‘ (Got an error reading communication packets)
[Warning] Aborted connection 81 to db:‘unconnected‘ user: ‘root‘ host: ‘127.0.0.1‘ (Got timeout reading communication
packets)
[Warning] Aborted connection 109 to db:‘helei1‘ user: ‘sys_admin‘ host: ‘192.168.1.1‘ (Got an error writing communication packets)
[Warning] Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)
[Warning] Got an error writing communication packets

Part3:重点参数分析

wait_timeout

Command-Line Format --wait-timeout=#
System Variable Name wait_timeout
Variable Scope Global, Session
Dynamic Variable Yes
Permitted Values (Windows) Type integer
Default 28800
Min Value 1
Max Value 2147483
Permitted Values (Other) Type integer
Default 28800
Min Value 1
Max Value 31536000

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

interactive_timeout

Command-Line Format --interactive-timeout=#
System Variable Name interactive_timeout
Variable Scope Global, Session
Dynamic Variable Yes
Permitted Values Type integer
Default 28800
Min Value 1

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

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


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

mysql> show global variables like ‘%timeout%‘;
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 10       |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 50       |
| innodb_rollback_on_timeout | OFF      |
|interactive_timeout        | 28800    |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 30       |
| net_write_timeout          | 60       |
| slave_net_timeout          | 3600     |
|wait_timeout               | 28800    |
+----------------------------+----------+
10 rows in set (0.01 sec)

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

mysql>show global status like ‘aborted%‘;
+------------------+-------+
|Variable_name    | Value |
+------------------+-------+
|Aborted_clients  | 19    |
|Aborted_connects | 0     |
+------------------+-------+
2 rows inset (0.00 sec)

Part4:案例1

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

[[email protected]~]# mysql -uroot -pwrongpass -h127.0.0.1
ERROR 1045 (28000): Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)
[[email protected]~]# mysql -uroot -pwrongpass -h127.0.0.1
ERROR 1045 (28000): Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)
[[email protected]~]# mysql -uroot -pwrongpass -h127.0.0.1
ERROR 1045 (28000): Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)
[[email protected]~]# mysql -uroot -pwrongpass -h127.0.0.1
ERROR 1045 (28000): Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)
[[email protected]~]# mysql -uroot -pwrongpass -h127.0.0.1
ERROR 1045 (28000): Access denied for user ‘root‘@‘127.0.0.1‘ (using password: YES)

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

mysql>show global status like ‘aborted%‘;
+------------------+-------+
|Variable_name    | Value |
+------------------+-------+
|Aborted_clients  | 19    |
|Aborted_connects | 5     |
+------------------+-------+
2 rows inset (0.00 sec)

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

[Warning] Access denied for user‘root‘@‘127.0.0.1‘ (using password: YES)
[Warning] Access denied for user ‘root‘@‘127.0.0.1‘ (using password:YES)
[Warning] Access denied for user ‘root‘@‘127.0.0.1‘ (using password:YES)
[Warning] Access denied for user ‘root‘@‘127.0.0.1‘ (using password:YES)
[Warning] Access denied for user ‘root‘@‘127.0.0.1‘ (using password:YES)

Part5:案例2

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

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

mysql>set global wait_timeout=10;
Query OK,0 rows affected (0.00 sec)
 
mysql>set global interactive_timeout=10;
Query OK,0 rows affected (0.00 sec)
mysql>show processlist;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect... Connection id: 79 Current database: *** NONE ***
 
+----+------+-----------------+------+---------+------+-------+------------------+
| Id |User | Host            | db   | Command | Time | State | Info             |
+----+------+-----------------+------+---------+------+-------+------------------+
| 79 |root | 127.0.0.1:42016 | NULL | Query  |    0 | NULL  | show processlist |
+----+------+-----------------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)

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

mysql>show global status like ‘aborted%‘;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect... Connection id:    81 Current database: *** NONE ***
 
+------------------+-------+
|Variable_name    | Value |
+------------------+-------+
|Aborted_clients  | 22    |
|Aborted_connects | 5     |
+------------------+-------+
2 rows in set (0.01 sec)

error log中记载的是

[Warning] Aborted connection 81 to db: ‘unconnected‘ user: ‘root‘ host: ‘127.0.0.1‘ (Got timeout reading communication packets)
[Warning] Aborted connection 78 to db: ‘unconnected‘ user: ‘root‘ host: ‘127.0.0.1‘ (Got timeout reading communication packets) 
[Warning] Aborted connection 79 to db: ‘unconnected‘ user: ‘root‘ host: ‘127.0.0.1‘ (Got timeout reading communication packets)

Part6:案例3

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

mysql>show global variables like ‘max_conn%‘;
+--------------------+-------+
|Variable_name      | Value |
+--------------------+-------+
|max_connect_errors | 1000  |
|max_connections    | 1024  |
+--------------------+-------+
2 rows in set (0.00 sec)
 
 
mysql>set global max_connections=2;
Query OK,0 rows affected (0.00 sec)

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

[[email protected]~]# mysql -uroot -pMANAGER -h127.0.0.1
ERROR 1040 (HY000): Too many connections

而错误日志没有任何记录

Part7:案例4

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

clients上涨

mysql>show global status like ‘aborted%‘;
+------------------+-------+
|Variable_name    | Value |
+------------------+-------+
|Aborted_clients  | 28    |
|Aborted_connects | 10    |
+------------------+-------+
2 rows in set (0.00 sec)

error log日志记录

170626 16:26:56 [Warning] Aborted connection 109 to db: ‘helei1‘ user: ‘sys_admin‘ host: ‘192.168.1.1‘ (Got an error writing communication packets)

Part8:原因总结

  1. 在MySQL中sleep状态数百秒的而且经常重复连接是应用程序在工作后没有关闭连接的症状之一,而是依靠数据库wait_timeout来关闭它们。强烈建议在操作结束时更改应用程序逻辑以正确关闭连接;
  2. 检查以确保max_allowed_packet的值足够高,并且客户端没有收到“数据包太大”消息。 这种情况他会中止连接,而不正确关闭它;
  3. 另一种可能性是TIME_WAIT。建议您确认连接被妥善管理并且是在应用端正常关闭;
  4. 确保事务正确提交(开始和提交),以便一旦应用程序“完成”连接,它将处于“clean”的状态;
  5. <br class="Apple-interchange-newline"><div id="inner-editor"></div>

    您应该确保客户端应用程序不中止连接。 例如,如果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错误是常见的错误,这类错误出现的时候脑海里要有一个理论知识,知道什么情况下,会出现什么样的错误,以便快速定位问题。由于者的水平有限,编写时间也很仓促,文中难免会出现一些错误或者不准确的地方,不妥之处恳请读者批评指正。

时间: 2024-10-26 10:20:55

MySQL令人头疼的Aborted告警案例分析的相关文章

161920、使用Spring AOP实现MySQL数据库读写分离案例分析

一.前言 分布式环境下数据库的读写分离策略是解决数据库读写性能瓶颈的一个关键解决方案,更是最大限度了提高了应用中读取 (Read)数据的速度和并发量. 在进行数据库读写分离的时候,我们首先要进行数据库的主从配置,最简单的是一台Master和一台Slave(大型网站系统的话,当然会很复杂,这里只是分析了最简单的情况).通过主从配置主从数据库保持了相同的数据,我们在进行读操作的时候访问从数据库Slave,在进行写操作的时候访问主数据库Master.这样的话就减轻了一台服务器的压力. 在进行读写分离案

使用Spring AOP实现MySQL数据库读写分离案例分析

一.前言 分布式环境下数据库的读写分离策略是解决数据库读写性能瓶颈的一个关键解决方案,更是最大限度了提高了应用中读取 (Read)数据的速度和并发量. 在进行数据库读写分离的时候,我们首先要进行数据库的主从配置,最简单的是一台Master和一台Slave(大型网站系统的话,当然会很复杂,这里只是分析了最简单的情况).通过主从配置主从数据库保持了相同的数据,我们在进行读操作的时候访问从数据库Slave,在进行写操作的时候访问主数据库Master.这样的话就减轻了一台服务器的压力. 在进行读写分离案

MySQL排序原理与案例分析

前言      排序是数据库中的一个基本功能,MySQL也不例外.用户通过Order by语句即能达到将指定的结果集排序的目的,其实不仅仅是Order by语句,Group by语句,Distinct语句都会隐含使用排序.本文首先会简单介绍SQL如何利用索引避免排序代价,然后会介绍MySQL实现排序的内部原理,并介绍与排序相关的参数,最后会给出几个“奇怪”排序例子,来谈谈排序一致性问题,并说明产生现象的本质原因. 1.排序优化与索引使用      为了优化SQL语句的排序性能,最好的情况是避免排

[转]MySQL排序原理与案例分析

这篇文章非常好,就把他转过来 前言      排序是数据库中的一个基本功能,MySQL也不例外.用户通过Order by语句即能达到将指定的结果集排序的目的,其实不仅仅是Order by语句,Group by语句,Distinct语句都会隐含使用排序.本文首先会简单介绍SQL如何利用索引避免排序代价,然后会介绍MySQL实现排序的内部原理,并介绍与排序相关的参数,最后会给出几个“奇怪”排序例子,来谈谈排序一致性问题,并说明产生现象的本质原因. 1.排序优化与索引使用      为了优化SQL语句

MySQL批量更新死锁案例分析--转载

问题描述 在做项目的过程中,由于写SQL太过随意,一不小心就抛了一个死锁异常,如下: [java] view plaincopyprint? com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.GeneratedConstructorAccessor24

MySql一个生产死锁案例分析

接到上级一个生产环境MySQL死锁日志信息文件,需要找出原因并解决问题.我将死锁日志部分贴出如下: 在mysql中使用命令:SHOW ENGINE INNODB STATUS;总能获取到最近一些问题信息,通过搜索deadlock 关键字即可找到死锁的相关日志信息. 2019-09-25 13:28:25 7fc0301ca700InnoDB: transactions deadlock detected, dumping detailed information. 2019-09-25 13:2

【MySQL】排序原理与案例分析

前言 排序是数据库中的一个基本功能,MySQL也不例外.用户通过Order by语句即能达到将指定的结果集排序的目的,其实不仅仅是Order by语句,Group by语句,Distinct语句都会隐含使用排序.本文首先会简单介绍SQL如何利用索引避免排序代价,然后会介绍MySQL实现排序的内部原理,并介绍与排序相关的参数,最后会给出几个"奇怪"排序例子,来谈谈排序一致性问题,并说明产生现象的本质原因. 排序优化与索引使用 为了优化SQL语句的排序性能,最好的情况是避免排序,合理利用索

MySQL SYS CPU高的案例分析(一)

原文:MySQL SYS CPU高的案例分析(一) [现象] 最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高. 下面的截图来源于“MySQL CPU报警”采集的文件 [问题分析] 可以分析出这服务器CPU升高的原因是由于表的高并发写入引起.优化方案通常是通知开发停止写入或降低写入频率. 究竟是什么原因导致高并发写入时CPU sys的占比这么高. 从采集的[Perf Stat]指标看到CPU有大量消耗是集中ke

(转)一个MySQL 5.7 分区表性能下降的案例分析

一个MySQL 5.7 分区表性能下降的案例分析 原文:http://www.talkwithtrend.com/Article/216803 前言 希望通过本文,使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱,避免在该版本上继续踩坑.同时通过对源码的分享,升级MySQL5.7.18时分区表性能下降的根本原因,向MySQL源码爱好者展示分区表实现中锁的运用. 问题描述 MySQL 5.7版本中,性能相关的改进非常多.包括临时表相关的性能改进,连接建立速度的优化和复制分发相关的性能改进