mysql server has gone away的缘由

 以前遇到开发询问“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日志中看到详细的信息了。