记录一次mysql数据库Broken pipe 报错的生产问题的处理

最新推荐文章于 2024-07-16 10:47:04 发布

原创

最新推荐文章于 2024-07-16 10:47:04 发布 · 2.2k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #mysql #java

在Spring Cloud阿里版项目中，使用MybatisPlus+Druid数据池连接MySQL 5.7时遇到Broken pipe错误。问题可能源于框架配置未设置连接池参数，如连接超时和有效性验证，以及数据库隔离装置代理插件性能问题导致的连接被kill。解决方案是优化Druid配置，增加连接有效性检查。

索引

一、问题说明
 二、源码
 三、结果

一、问题说明

框架使用spirng cloud 阿里版本，JPA使用mybatisPlus + druid 数据池，数据库采用mysql 5.7，因生产环境网络原因，应用程序连接mysql 中间使用隔离装置代理插件进行连接，应用程序正常部署后，使用时间不超10分钟，后台程序会报出SqlException：Broken pipe 管道破裂错误，程序无法恢复，所有连接失效。

报错原图
经过查阅资料及一系列分析，这个问题的产生与mysql 经典的 8小时问题非常类似，参考博客：mysql经典的8小时问题-wait_timeout

1. 自身项目框架问题分析

系统使用了JPA使用mybatisPlus + druid 数据池，在mybatisPlus的配置文件中未对druid进行配置，使用的是druid默认配置，默认配置中连接池初始化连接数为0，最大连接数为8，未配置sql超时时间、连接有效验证等参数。

2. 网络数据库隔离装置代理插件问题分析

系统连接mysql 使用数据库隔离装置代理插件，代理插件性能很一般，连续发送几个列表查询sql 都会引起代理插件CPU飙升。鉴于这个代理插件性能，当程序发送大量sql 请求到达代理插件时，代理插件自我保护机制会将程序连接代理插件的sql连接主动kill掉，以防止代理插件服务宕机。
因应用程序与数据库之间的连接都为长连接，服务端代理插件断掉连接后，客户端应用程序没有进行连接的有效性检查，导致连接池内的连接全部无效，程序没法连接数据库，报出 Broken pipe 异常。