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的官网上了解。