MySQL Aborted告警案例分析
MySQL Aborted告警案例分析
昨天频繁的收到MySQL实例关于Aborted告警邮件，看到告警邮件的实例信息，测试实例，优先级没没那么高，晚点抽空在看，可能到时候就好了，抱着侥幸的心理继续划水，但是没过1个小时，收到50多封告警邮件，实在受不了了，准备放下手头的事情优先处理该告警问题； 如下是告警邮件相关信息截图：
从告警看，是由于MySQL实例状态变量Aborted_connects不断增加导致的，正常情况下，该变量值应该保持0，但是现在在不断的累加，那么在什么情况下该状态值会不断的增加呢？这是解决该问题最先需要弄清楚的；
那么先看一下具体的现象:
Aborted_connects的值不断的增加，系统层面存在大量的TIME_WAIT状态的TCP连接，而且都来自于同一个IP地址，如下所示：
# netstat -tuplan | grep 4306 | grep TIME_WAIT | wc -l
1159
下面是部分tcp连接
......
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7586 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:5198 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:8314 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:5076 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7610 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7962 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:6546 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:5354 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:6596 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:8342 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7184 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7476 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:5994 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:7322 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:5340 TIME_WAIT -
tcp 0 0 192.168.7.xxx:4306 10.21.1.28:6798 TIME_WAIT -实例层面可以看到，Aborted_connects的值不断的增加
mysql> show status like '%aborted%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Aborted_clients | 4356 |
| Aborted_connects | 112524|
+------------------+-------+
2 rows in set (0.00 sec)那么，先来看一下错误日志，看看错误日志中是否有相关记录，但是查看错误日志，并没有发现错误信息；感觉很疑惑；
接来下，我们先看一下在什么情况下Aborted_connects的值会不断的增加？
如下是官方文档针对该状态量的解释以及该变量不断增加可能产生的原因的说明：
Aborted_connects
The number of failed attempts to connect to the MySQL server.
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.
从上面可以看到，如上的四种情况会导致该变量值不断增加：
- 客户端尝试连接数据库，但是没有权限
- 客户端使用了错误的密码
- 连接的数据包包含不正确的信息
- 超过连接时间限制，主要有这个参数控制connect_timeout，mysql默认是10s，基本除非网络环境极端不好，一般不会超时
但是从错误日志中并没有发现有用的信息，接下来，打开general_log来看一下数据库相关的操作信息，开启后，发现了新大陆，general_log日志中记录了大量如下的日志：
2021-11-18T09:16:19.234261Z 8328 Connect dev_test_rwh@10.21.1.28 on game_report_sg using SSL/TLS
2021-11-18T09:16:19.255753Z 8329 Connect dev_test_rwh@10.21.1.28 on game_report_sg using SSL/TLS
2021-11-18T09:16:19.352826Z 8330 Connect dev_test_rwh@10.21.1.28 on game_report_sg using SSL/TLS
2021-11-18T09:16:19.452269Z 8331 Connect dev_test_rwh@10.21.1.28 on game_report_sg using SSL/TLS从该日志信息看，可以发现，从客户端10.21.1.28发起连接，通过dev_test_rwh账户连接数据库game_report_sg，但是可以发现，该账户却没有数据库game_report_sg的访问权限导致，那么正常情况，没有访问权限连接的客户端应该会会出现报错信息，于是连接业务人员查看相关连接情况，最终把该问题解决掉；