欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

mysql server has gone away的原因_MySQL

程序员文章站 2022-03-14 09:30:35
...

之前遇到开发询问“mysql server has gone away”的问题,想当然的就认为是由于太长时间没有操作,导致超过MySQL服务端上的wait_timeout的设置,最终连接被MySQL服务端回收了。

最近一次突然自己同事写的脚本在运行过程中被中断了,查看报错信息依然是“mysql server has gone away”,同事的脚本在多个MySQL实例上根据时间范围取值,虽然执行时间长了点,但是绝对不会有超过wati_timeout的空闲等待时间,于是去学习了一下到底有哪几种情况会出现这个报错。

情况1

就是最常见的,一个链接超过wait_timeout的设置时间没有做任何事情,被MySQL服务端关闭链接并回收资源。
针对这种情况要不调大wait_timeout或者不断的向MySQL服务端发送心跳信号,保持链接。

情况2

你的链接被kill掉了,有可能是DBA人工操作,也可能是各种自动化系统操作,可以通过监控status中com_kill状态值来判断刚才是否发生了kill操作。

情况3

MySQL的客户端如果默认配置中有mysql_opt_read_timeout或者mysql_opt_write_timeout参数,并且操作时间超过了其中一个参数的设置,客户端自身会关闭链接。所以需要了解自己使用的mysql客户端。

情况4

还有一种可能是发送的请求或者返回的结果集太大了,超过MySQL的max_allowed_packet_size的设置,导致发生这种报错。多说一句,这个参数需要客户端和服务端同时配置并保持一致才会生效。
最常见的Linux上的mysql客户端可以使用如下命令查看:

mysql --help | grep ^max-allowmax-allowed-packet 1677721

我们可以看到我们服务器上默认的设置为16M。

情况5

这种比较罕见的情况是MySQL服务端的DNS反解失败导致,理论上我们可以配置–skip-networking参数来规避这种问题。(但是官方文档居然说即使配置了也可能出现这种报错,T_T)

情况6

还有就是如果程序使用了多进程,而所有进程都尝试使用同一个链接和MySQL服务端建立链接的时候就会出现gone away的报错了。(初步怀疑,这也就是我同事遇到的问题了。)

情况7

最后这种比较弱,但是真实发生过,那就是mysql实例宕机了。实例都没有了,自然什么都没有了。当然这种情况判断起来比较方便,一般都会有mysql的存活监控。但是要小心一种情况,就是实例crash后迅速recover,如果监控程序的间隔大于recover的时间,那么就很难发现了。建议使用如下方法复查一下,另外针对uptime最好做为状态的一个必要监控点。

show global status like 'uptime';+---------------+---------+| Variable_name | Value   |+---------------+---------+| Uptime        | 1230699 |+---------------+---------+

最后如果想对“mysql server has gone away”进行详细的追查,建议在mysqld实例启动的时候添加–log-warnings=2 参数,这样就可以在error日志中看到详细的信息了。

相关标签: 开发