客户跟我反馈他们的数据库通过客户端数据库工具连接不上了,并且截图我看了,数据库是mysql
报错内容"MySQL error: 2013, “Lost connection to MySQL server at ‘reading initial communication packet‘, system error: 0""
2丶思路分析
- 查看数据库错误日志
- 查看系统日志
3丶开始排查
【第一步】
开启两个"session",一个用于实时监控mysql的错误日志,而且奇怪的是错误日志最后一条信息的输出时间为2020/08/04,
我就觉得很奇怪,今天都8月5号来了,难道这段时间数据库都不输出日志的吗?
但是由于间隔时间不长,然后数据库也连接不上,我先入为主的认为可能数据库已经假死,
导致日志信息都不输出,所以我并没有在意!
【第二步】
我开始启动数据库,但是还是启动失败,但是错误日志还是没有任何输出,我就觉得很奇怪,
"磁盘空间也没满",为什么我连重启数据库怎么也不输出错误日志呢,没错误日志排查不就是盲查吗?
【第三步】
错误日志行不通,于是我就去看了下系统日志message,或许能找到点有用的信息,
突然发现里面打印了一条"no many open file",难道是因为进程打开的文件数超过了默认的设置限制吗?
我通过"ulimit -n" 看了下发现进程打开的文件数是65535而我mysql这刚启动怎么可能出现超过"65535"的可能,
于是我判断应该是有某个进程打开了文件数超过了"65535",但是我又不想也不对啊,
即使某个进程超过了"65535"的限制但是我"mysql"不受影响啊,难道是说系统打开的文件数达到了上限?
于是我通过"sysctl -a|grep fs.file"查看系统的限制发现也是"65535",原来是系统达到了临界点了,
于是我就通过"lsof |wc -l "查看当时系统打开的文件数,发现已经达到"70000"多了,终于找到了原因了
-
排序当前系统中打开文件数前十的进程
lsof |awk ‘{print $1}‘|sort|uniq -c |sort -nr|head -10 - 确认java进程打开的文件数
【第四步】
找到了原因接下来就是查看哪个进程打开的文件数最多了,发现是"java程序导致"的,
于是就反馈给我们客户让他找相关的开发同事着重排查下,
是不是打开文件的时候未"close"文件
总结
1丶由于系统打开文件数上限,导致mysql错误日志无任何日志输出
2丶不要盲目的去尝试,通过看日志排错是最好的选择
3丶当自己的才华不足以满足自己的野心时,记得静下心来学习
MYSQL数据库连接异常【ERROR:2013】
原文地址:https://blog.51cto.com/12898848/2517419