这篇文章主要介绍MySQL中异常的客户端连接怎么处理，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
背景1:
程序反馈数据库出现了max_connection的错误, 导致client无法连接到db;
根据程序的说法, 使用大量的连接是历史遗留问题, 遂调高了max_connection的参数;
背景2:
另外一个业务的程序发现数据库中出现了一些连接时间很长的sleep连接, 但是应用层已经把所有的进程全部重启了;
如截图:
10s多的是重启后新建的连接, 3000左右的是异常链接;
场景:
未搭建复现场景;
分析:
第一时间考虑的就是应用服务器上还有遗漏的进程没有关闭, 所以导致了这些连接一直保持着;
程序在检查之后一再保证确实没有连接数据库的进程以后, 开始顺着网络链路进行分析;
首先让程序停掉了应用层的所有进程, 然后发现MySQL上确实只留下了持续好几千秒的sleep连接;
在DB的服务器上也能看到EST的TCP/IP连接, 确认了连接还是存在的;
然后检查了MySQL前端的haproxy服务器, 比对了一下端口, 也找到了haproxy上的连接;
反查haproxy的连接信息, 找到了应用服务器的IP和对应的端口, 如截图:
奇怪的是, 应用服务器上并没有端口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的超时时间以后, 这种现象不再出现, 问题解决~
以上是“MySQL中异常的客户端连接怎么处理”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注创新互联-成都网站建设公司行业资讯频道！
