connection was bad 真实案例

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

一、背景:

         业务反映他们程序端日志最近老有“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。

 

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

原文地址:https://www.cnblogs.com/igoodful/p/14261512.html