mysqldump备份失败案例一则

mysqldump备份失败案例一则

日常运维过程中，经常会使用到mysqldump工具来对线上的库表进行备份。

今天下午在线上遇到了一个业务反馈mysqldump频繁失败，大概的错误日志如下：

mysqldump --max_allowed_packet=1024M --single-transaction -uxxx -pxxx -h xxx -P xxx --databases xxx > a.sql mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `issue` at row: 13705

上述报错，有时间规律，一般是执行8s~15s之间，就被kill掉了。

这个报错信息，比较常见，意思是在备份的过程中，丢失了和MySQL的连接。

根据已知的信息分析，通常情况下，这种问题是由下面几个原因造成的：

1、net_write_timeout参数

它代表的是服务器往客户端写数据的时候的超时时间。超过这个时间，将会主动断开连接。对应的还有一个net_read_timeout参数，代表服务器从客户端读数据的超时时间。

2、max_allowed_packet参数

它代表的是MySQL服务器和客户端 的通信包的大小，在MySQL侧，默认值是64MB，最大可以设置为1G大小。如果你要备份的表的字段超出了这个参数限制，那么这个mysqldump的连接就会被中断

3、mysqldump备份的时候，在等待锁，最终由于等待超时，连接被kill掉了。

一开始，排查思路也是上面几个，调大了相关参数的阈值，最后发现都无法修复这个报错信息。

经过仔细分析报错，可以判断出来，一定是由于某种特殊情况，导致这个被mysqldump的进程被断开了。既然要断开这个mysqldump的连接，可能的情况有2种：

一种是不满足MySQL的某些限制，例如超时时间、通信包大小等；

第二种是人为、或者工具kill。

根据上面的思路，最终问题定位：

这个MySQL的端口上，历史上配置了过载保护机制，利用pt-kill工具，会定时杀掉那些查询时间较长的SQL。这个mysqldump执行的时间比较长，正好命中了这个kill策略，因此就被pt-kill工具杀掉了。

停止掉这个pt-kill的进程之后，mysqldump就能够正常执行了。

pt-kill这个工具是percona-toolkit包里面的一个工具，可以自动监控某些频繁出现、运行时间较长的重复SQL语句，并且自动帮我们kill掉，避免MySQL服务查询负载过高。保证MySQL服务的可用性。具体使用方法，大家可以去percona的官网上了解。