转载

MySQL--异常的客户端连接

-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景1:
程序反馈数据库出现了max_connection的错误, 导致client无法连接到db;
根据程序的说法, 使用大量的连接是历史遗留问题, 遂调高了max_connection的参数;

背景2:
另外一个业务的程序发现数据库中出现了一些连接时间很长的sleep连接, 但是应用层已经把所有的进程全部重启了;
如截图:
MySQL--异常的客户端连接

10s多的是重启后新建的连接, 3000左右的是异常链接;

场景:
未搭建复现场景;

分析:
第一时间考虑的就是应用服务器上还有遗漏的进程没有关闭, 所以导致了这些连接一直保持着;
程序在检查之后一再保证确实没有连接数据库的进程以后, 开始顺着网络链路进行分析;

首先让程序停掉了应用层的所有进程, 然后发现MySQL上确实只留下了持续好几千秒的sleep连接;
在DB的服务器上也能看到EST的TCP/IP连接, 确认了连接还是存在的;
然后检查了MySQL前端的haproxy服务器, 比对了一下端口, 也找到了haproxy上的连接;
反查haproxy的连接信息, 找到了应用服务器的IP和对应的端口, 如截图:
MySQL--异常的客户端连接

奇怪的是, 应用服务器上并没有端口38710的这些信息, 新创建的端口都已经到48000以后去了;
那么haproxy上, 这些与不存在端口的连接到底是什么原理?

和网络部分的同事说明情况以后, 最终给出了一个解释:
client在连接DB的时候会经由LVS转发到haproxy, 其中LVS的超时时间设置比haproxy短;
因此client在保持空闲一段时间以后, 再访问LVS时, LVS会告知client重新向haproxy发起新的连接,
迩haproxy上旧的连接因为还没有到haproxy的超时时间, 所以也没有断开, 那么在查询的时候就会出现这种没有源头的链接;

处理方式:
在发现了这个问题的haproxy实例上, 调整了haproxy的超时时间, 比LVS略高, 之后的几天内, 这种连接不再出现;
且haproxy断开连接时, MySQL的error log中出现了一些NOTE提醒有连接被断开了;

背景2中, 其实也是这个原因, 导致了在MySQL端堆积了大量的sleep连接, 结果把可用的connection都挤占了, 导致client无法再连接DB;
统一修改了haproxy的超时时间以后, 这种现象不再出现, 问题解决~

PS: 这种异常的sleep连接, 程序肯定有一部分的责任, 不过在解决问题的角度来说, 一方面提醒程序要注意DB连接的处理, 一方面也要在其他方面做好最后一道防线;

正文到此结束