mysql关于Aborted_connects总出现大于0的问题

发布时间:2019-12-13 05:23    浏览次数 :

[返回]

mysql关于Aborted_connects总出现大于0的问题

 

 

关于MySQL的状态变量Aborted_clients & Aborted_connects分别代表的意义,以及哪些情况或因素会导致这些状态变量变化呢?下文通过实验测试来验证一下,首先我们来看看状态变量的描述:

在我的数据库里头,我每天看Aborted_connects这个参数,每天都会大于0个,有时几十,有时是几百,其实我每天都会重启一次mysql库的,如果我每天起两次就不会出现Aborted_connects大于0的情况,所以我想问问各位,我该修改什么参数才能控制这个值,使它正常呢?我的max_conntions设了有1000个。  www.2cto.com  

 

 

 

解决办法:

Aborted Connect

前几天我也碰到了同样的问题,你用下面的方法重新启动一下,我就是用下面的方法解决的,希望也同样适用你。

 

 

Aborted Connect表示尝试连接到MySQL服务器失败的次数。这个状态变量可以结合host_cache表和其错误日志一起来分析问题。 引起这个状态变量激增的原因如下:

当用show processlist;看到如下信息时 

 

unauthenticated user | 192.168.0.3:1112 | NULL | Connect | NULL | login | NULL 

 

 

    1、 客户端没有权限但是尝试访问MySQL数据库。

1、启动时带参数  --skip-name-resolve 

 

 

    2、 客户端输入的密码有误。

2、访问的主机授权时用IP,最好把该主机的IP及主机名写到/etc/hosts文件中.

 

在我的数据库里头,我每天看Aborted_connects这个参数,每天都会大于0个,有时几十,有时是几百,其实我每...

    3、 A connection packet does not contain the right information.

 

   4、 超过连接时间限制,主要是这个系统变量connect_timeout控制(mysql默认是10s,基本上,除非网络环境极端不好,一般不会超时。)

 

官方解释如下:

 

 

If a client is unable even to connect, the server increments the Aborted_connects status variable. Unsuccessful connection attempts can occur for the following reasons:

 

·         A client attempts to access a database but has no privileges for it.

 

·         A client uses an incorrect password.

 

·         A connection packet does not contain the right information.

 

·         It takes more than connect_timeout seconds to obtain a connect packet. See Section 5.1.7, “Server System Variables”.

 

 

 

 

 

 

Aborted Clients:

** 

 

Aborted Clients表示由于客户端没有正确关闭连接而中止的连接数。官方解释如下:

  

   The number of connections that were aborted because the client died without closing the connection properly. See Section B.5.2.10, “Communication Errors and Aborted Connections”

 

 

当Aborted Clients增大的时候意味着有客户端成功建立连接,但是由于某些原因断开连接或者被终止了,这种情况一般发生在网络不稳定的环境中。主要的可能性有:

 

 

 

   1、 客户端程序在退出之前未调用mysql_close()正确关闭MySQL连接。

  

   2、 客户端休眠的时间超过了系统变量wait_timeout和interactive_timeout的值,导致连接被MySQL进程终止

 

   3、 客户端程序在数据传输过程中突然结束

 

 

官方文档B.5.2.10 Communication Errors and Aborted Connections的介绍如下:

 

 

 

If a client successfully connects but later disconnects improperly or is terminated, the server increments the Aborted_clients status variable, and logs an Aborted connection message to the error log. The cause can be any of the following:

 

 

·         The client program did not call mysql_close() before exiting.

 

·         The client had been sleeping more than wait_timeout or interactive_timeout seconds without issuing any requests to the server. See Section 5.1.7, “Server System Variables”.

 

·         The client program ended abruptly in the middle of a data transfer.

 

 

 

 

 

Other reasons for problems with aborted connections or aborted clients:

 

·         The max_allowed_packet variable value is too small or queries require more memory than you have allocated for mysqld. See Section B.5.2.9, “Packet Too Large”.

 

·         Use of Ethernet protocol with Linux, both half and full duplex. Some Linux Ethernet drivers have this bug. You should test for this bug by transferring a huge file using FTP between the client and server machines. If a transfer goes in burst-pause-burst-pause mode, you are experiencing a Linux duplex syndrome. Switch the duplex mode for both your network card and hub/switch to either full duplex or to half duplex and test the results to determine the best setting.

 

·         A problem with the thread library that causes interrupts on reads.

 

·         Badly configured TCP/IP.

 

·         Faulty Ethernets, hubs, switches, cables, and so forth. This can be diagnosed properly only by replacing hardware.

 

 

 

如上介绍所示,有很多因素引起这些状态变量的值变化,那么我们来一个个分析、演示一下吧。首先,我们来测试一下导致Aborted Connect状态变量增加的可能因素

 

 

1、 客户端没有权限但是尝试访问MySQL数据库。

 

 

其实这里所说的没有权限,个人理解是:客户端使用没有授权的账号访问数据库 。打个比方,你尝试用账号kkk访问MySQL数据库,其实你也不知道数据库是否存在这个用户,实际上不存在这个用户。

 

实验对比测试前,先将状态变量清零。

 

mysql> flush status;

Query OK, 0 rows affected (0.01 sec)

mysql> show status like 'Abort%';

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

| Variable_name    | Value |

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

| Aborted_clients  | 0     |

| Aborted_connects | 0     |

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

2 rows in set (0.01 sec)

 

mysql> 

mysql> select host,user from mysql.user;

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

| host                          | user      |

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

| %                             | mydba     |

| %                             | root      |

| %                             | test      |

| 127.0.0.1                     | root      |

| 192.168.%                     | mydbadmin |

| 192.168.103.18,192.168.103,22 | LimitIP   |

| ::1                           | root      |

| db-server.localdomain         | root      |

| localhost                     | backuser  |

| localhost                     | root      |

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

 

 

在本机的SecureCRT的另外一个窗口,使用不存在的账号kkk访问MySQL后,你会发现状态变量Aborted_connects变为1了。

 

 

[root@DB-Server ~]# mysql -u kkk -p

Enter password:

ERROR 1045 (28000): Access denied for user 'kkk'@'localhost' (using password: YES)

 

 

图片 1

 

 

也有可能,这个账号本身存在,但是只允许特定IP地址才能访问,实际环境中,可能是有人在进行尝试暴力破解。可能性非常多。我们来测试一下限制IP访问的情况

 

mysql> grant all on MyDB.* to mydbadmin@'10.20.%' identified by '123456';

Query OK, 0 rows affected (0.01 sec)

 

mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec)

 

mysql>  show status like 'Abort%';

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

| Variable_name    | Value |

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

| Aborted_clients  | 0     |

| Aborted_connects | 0     |

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

2 rows in set (0.00 sec)

 

 

如上所示,创建一个mydbadmin的行号,只允许10.20段的IP访问,然后我们从192.168段的IP访问MySQL数据库

 

 

 

# mysql -h 10.20.57.24 -u mydbadmin -p

Enter password:

ERROR 1045 (28000): Access denied for user 'mydbadmin'@'192.168.7.208' (using password: YES)

 

此时,状态变量Aborted_connects就变为1了。

 

图片 2

 

 

 

2、 客户端输入的密码有误或者根本就是尝试各个密码。(A client uses an incorrect password)

 

如下所示,使用test账号访问MySQL数据,但是输入了一个错误密码

 

[root@DB-Server ~]# mysql -u test -p

Enter password:

ERROR 1045 (28000): Access denied for user 'test'@'localhost' (using password: YES)

[root@DB-Server ~]#

 

你检查状态变量Aborted_connects就会发现状态变量Aborted_connects变为2了。

 

mysql>  show status like 'Abort%';

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

| Variable_name    | Value |

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

| Aborted_clients  | 0     |

| Aborted_connects | 2     |

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

2 rows in set (0.00 sec)

 

 

3: A connection packet does not contain the right information.

 

 

这个比较容易构造,可以对MySQL的端口进行端口测试(ping 端口),因为psping的包不包含正确的信息(right information),测试之前,先将状态变量清空。

 

 

mysql> flush status;

 Query OK, 0 rows affected (0.00 sec)

mysql> show status like 'abort%';

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

| Variable_name    | Value |

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

| Aborted_clients  | 0     |

| Aborted_connects | 0     |

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

2 rows in set (0.00 sec)

 

 

在客户端对MySQL服务所在的主机进行端口连通性验证(psping)

 

 

 

 

图片 3

 

 

 

如上所示,psping测试后,Aborted_connects变成了5,如果继续进行psping测试,那么这个状态变量就会继续增长。

 

 

图片 4

 

 

 

 

另外,如果超过max_connect_error的限制后,某一个客户端持续访问MySQL,这个是否会引起状态变量Aborted_connects变化呢,实验测试的答案是不会。有兴趣的可以验证一下,很奇怪,网上有不少文章都说如果连接数满了,也会导致Aborted_connects状态变量增加,实际上这个是不会引起状态变量Aborted_connects变化的。

 

 

 

  4、 超过连接时间限制,主要是这个参数connect_timeout控制(mysql默认是10s,基本上,除非网络环境极端不好,一般不会超时。)

 

 

 

首先在一台MySQL数据库服务器上执行下面命令,我们用Linux下的netem与tc命令模拟构造出复杂环境下的网络传输延时案例,延时11秒。

 

 

# tc qdisc add dev eth0 root netem delay 11000ms

 

 

在另外一台MySQL服务器ping这台MySLQ服务器,如下所示,你会看到网络时延为11秒

 

 

# ping 10.20.57.24

PING 10.20.57.24 (10.20.57.24) 56(84) bytes of data.

64 bytes from 10.20.57.24: icmp_seq=1 ttl=61 time=11001 ms

64 bytes from 10.20.57.24: icmp_seq=2 ttl=61 time=11001 ms

64 bytes from 10.20.57.24: icmp_seq=3 ttl=61 time=11001 ms

64 bytes from 10.20.57.24: icmp_seq=4 ttl=61 time=11001 ms

64 bytes from 10.20.57.24: icmp_seq=5 ttl=61 time=11001 ms