<span>connection was bad 真实案例</span>

####################################

一、背景：

         业务反映他们程序端日志最近老有“connection was bad”报错，

         服务端程序语言为：golang

         数据库驱动程序：golang自带的驱动

         数据库架构：lvs+kingshard+mysql的一主多从集群

具体报错日志如下图也：

业务方程序访问数据库：

二、原因：

        由于业务方之前有大量的慢查询，当时为了不让数据库奔溃，跟业务商量后，决定暂时杀掉这些慢查询，以免影响其他查询，所以，当时就给这个mysql集群的每个实例都配置了一个杀掉慢查询定时任务，该任务如下：

/usr/local/bin/pt-kill --host=xxx --user=root --password=root --match-info=select|SELECT --victims=all --interval 30 --busy-time 300 --kill --print --daemon

       由于该任务中配置了-match-info=select|SELECT 和 --busy-time 300，表示查询时间超过了300s的sql就会被pt-kill工具给杀掉，因此业务方的sql由于有慢查询，且时间超过了300s，所以就会给业务方直接杀掉了，因此报该错误，由于时间好几个月了，自己也忘记了配置的这个任务，因此定位时间花了我一个周，开始以为是业务方没有按照lvs的连接超时机制来配置，然后让业务方按照要求配置，结果业务方按照要求配置了后，还是有这样的报错，于是业务方拿出了sql语句，开始怀疑是慢查询，我这边在kingshard日志中也获取到了这个sql的报错，于是手动直连一个数据库从库进行查询，结果在300s的时候就出现了：ERROR 2013 (HY000): Lost connection to MySQL server during query

     于是，开始怀疑到了pt-kill定时任务，结果一查看，果然有这个pt-kill任务在跑。

三、解决：

         和业务商量后，决定这个定时任务暂时还是不取消，业务自己改进下sql。

##################################