关于Aborted connection告警日志的分析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 有时候,连接MySQL的会话经常会异常退出,错误日志里会看到"Got an error reading communication packets"类型的告警。本篇文章我们一起来讨论下该错误可能的原因以及如何来规避。

1.状态变量Aborted_clients和Aborted_connects


首先我们来了解下Aborted_clients和Aborted_connects这两个状态变量的含义,当出现会话异常退出时,这两个状态值会有变化。根据官方文档描述,总结如下:


image.png

image.png



造成Aborted_connects状态变量增加的可能原因:

  1. 客户端试图访问数据库,但没有数据库的权限。
  2. 客户端使用了错误的密码。
  3. 连接包不包含正确的信息。
  4. 获取一个连接包需要的时间超过connect_timeout秒。


image.png

image.png


造成Aborted_clients状态变量增加的可能原因:


  1. 程序退出前,客户机程序没有调用mysql_close()。
  2. 客户端睡眠时间超过了wait_timeout或interactive_timeout参数的秒数。
  3. 客户端程序在数据传输过程中突然终止。


简单来说即:数据库会话未能正常连接到数据库,会造成Aborted_connects变量增加。数据库会话已正常连接到数据库但未能正常退出,会造成Aborted_clients变量增加。


2.Got an error reading communication packets原因分析


哪种情况会导致error log中出现“Aborted connection xxxx to db: 'db' user: 'dbuser' host: 'hostname' (Got an error reading communication packets)”类似告警呢?下面我们根据上面可能的原因来做下具体测试。每次测试要注意状态变量Aborted_clients和Aborted_connects的变化及错误日志记录。


  • 测试一:错误密码,错误用户

1.测试前查看状态变量值
mysql> show global status like 'abort%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 0     |
| Aborted_connects | 0     |
+------------------+-------+
2.测试过程
# mysql -uroot -pwrongpass
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
# mysql -uroot1 -pwrongpass
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'root1'@'localhost' (using password: YES)
3.查看状态变化及错误日志
mysql> show global status like 'abort%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 0     |
| Aborted_connects | 2     |
+------------------+-------+
错误日志记录:
2020-03-16T17:58:35.318819+08:00 6 [Note] Access denied for user 'root'@'localhost' (using password: YES)
2020-03-16T17:59:04.153753+08:00 7 [Note] Access denied for user 'root1'@'localhost' (using password: YES)
结果:Aborted_connects有增加 error log无Aborted connection相关记录
  • 测试二:睡眠时间超时或手动杀会话

1.测试前查看状态变量值
mysql> show global status like 'abort%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 0     |
| Aborted_connects | 2     |
+------------------+-------+
2.手动杀会话测试
mysql> show processlist;
+----+------+-----------+------+---------+------+----------+------------------+
| Id | User | Host      | db   | Command | Time | State    | Info             |
+----+------+-----------+------+---------+------+----------+------------------+
|  9 | root | localhost | NULL | Query   |    0 | starting | show processlist |
| 10 | root | localhost | NULL | Sleep   |    7 |          | NULL             |
+----+------+-----------+------+---------+------+----------+------------------+
2 rows in set (0.00 sec)
mysql> kill 10;
Query OK, 0 rows affected (0.00 sec)
3.查看状态变化及错误日志
mysql> show global status like 'abort%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 1     |
| Aborted_connects | 2     |
+------------------+-------+
结果:Aborted_clients有增加 error log无记录 ,
类似的,睡眠时间超时后Aborted_clients有增加 error log中有Aborted connection相关记录。

会话异常退出一般会造成Aborted connection告警,即我们可以通过Aborted_clients状态变量的变化来反映出是否存在异常会话,那么出现“_Got an error reading communication packets” _类似告警的原因就很明了了,查询相关资料,总结出造成Aborted connection告警的可能原因如下:


  1. 会话链接未正常关闭,程序没有调用mysql_close()。
  2. 睡眠时间超过wait_timeout或interactive_timeout参数的秒数。
  3. 查询数据包大小超过max_allowed_packet数值,造成链接中断。
  4. 其他网络或者硬件层面的问题。


3.问题避免与总结


其实Aborted connection告警是很难避免的,error log里或多或少会有少量Aborted connection信息,这种情况是可以忽略的,但是当你的error log里频繁出现Aborted connection告警,这时候就应该注意了,可能会对业务产生较大的影响。下面列举出几点避免错误的建议,希望对你有所帮助。


  1. 建议业务操作结束后,应用程序逻辑会正确关闭连接,以短连接替代长连接。
  2. 检查以确保max_allowed_packet的值足够高,并且客户端没有收到“数据包太大”消息。
  3. 确保客户端应用程序不中止连接,例如,如果PHP设置了max_execution_time为5秒,增加connect_timeout并不会起到作用,因为PHP会kill脚本。其他程序语言和环境也有类似的安全选项。
  4. 确保事务提交(begin和commit)都正确提交以保证一旦应用程序完成以后留下的连接是处于干净的状态。
  5. 检查是否启用了skip-name-resolve,检查主机根据其IP地址而不是其主机名进行身份验证。
  6. 尝试增加MySQL的net_read_timeout和net_write_timeout值,看看是否减少了错误的数量。


参考:


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
26
分享
相关文章
MiniMax GenAI 可观测性分析 :基于阿里云 SelectDB 构建 PB 级别日志系统
基于阿里云SelectDB,MiniMax构建了覆盖国内及海外业务的日志可观测中台,总体数据规模超过数PB,日均新增日志写入量达数百TB。系统在P95分位查询场景下的响应时间小于3秒,峰值时刻实现了超过10GB/s的读写吞吐。通过存算分离、高压缩比算法和单副本热缓存等技术手段,MiniMax在优化性能的同时显著降低了建设成本,计算资源用量降低40%,热数据存储用量降低50%,为未来业务的高速发展和技术演进奠定了坚实基础。
MiniMax GenAI 可观测性分析 :基于阿里云 SelectDB 构建 PB 级别日志系统
Zabbix告警分析新革命:DeepSeek四大创新场景助力智能运维
面对日益复杂的IT环境,高效分析监控数据并快速响应成为运维的关键挑战。本文深入探讨了DeepSeek与Zabbix结合的创新应用,包括一键式智能告警分析、Zabbix文档知识库助手及钉钉告警增强功能。通过部署指南和实用脚本,展示了如何提升故障排查效率,为运维工程师提供高效解决方案。
107 5
Zabbix告警分析新纪元:本地DeepSeek大模型实现智能化告警分析
本文由Zabbix中国峰会演讲嘉宾张世宏撰写,介绍如何通过集成Zabbix监控系统与深度求索(DeepSeek)AI助手,构建智能化告警处理方案。该方案利用Webhook机制传递告警信息,借助DeepSeek的智能分析能力,帮助运维团队快速识别问题根源并提供解决方案。文章详细描述了技术架构、环境搭建、Webhook配置及实际案例,展示了AI在运维领域的应用前景和优势。
253 0
让跨 project 联查更轻松,SLS StoreView 查询和分析实践
让跨 project 联查更轻松,SLS StoreView 查询和分析实践
智能日志分析:用AI点亮运维的未来
智能日志分析:用AI点亮运维的未来
433 15
基于阿里云 EMR Serverless Spark 版快速搭建OSS日志分析应用
基于阿里云 EMR Serverless Spark 版快速搭建OSS日志分析应用
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
129 7
MySQL事务日志-Undo Log工作原理分析
Linux--深入理与解linux文件系统与日志文件分析
深入理解 Linux 文件系统和日志文件分析,对于系统管理员和运维工程师来说至关重要。文件系统管理涉及到文件的组织、存储和检索,而日志文件则记录了系统和应用的运行状态,是排查故障和维护系统的重要依据。通过掌握文件系统和日志文件的管理和分析技能,可以有效提升系统的稳定性和安全性。
79 7
启用Linux防火墙日志记录和分析功能
为iptables启用日志记录对于监控进出流量至关重要
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
292 3

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等