首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

MySQL - 8小时连接闲置超时

,由于连接池里的连接长时间闲置着,而MySQL默认的非交互式连接的闲置时间是8小时;也就是说,当连接池里的连接闲置超过8小时后就会被MySQL数据库自动断开而失效。...由于连接池并不知道连接已经失效了,依然保持着这些失效连接,这导致web项目在一段时间后访问页面时报错,而在刷新页面后连接池重新获取了有效的连接,所以项目又可以正常访问了。...将生成的复件重命名成my.ini;然后在文件中添加如下语句: 1 2 wait_timeout=31536000 interactive_timeout=31536000 如果没有这两个语句则表示默认值是8小时...在项目中设置连接池的属性 我的项目是使用的c3p0,所以这里只介绍c3p0的设置方法,如下: 方法一:减少连接池内连接的生存周期 既然MySQL连接的默认闲置时间是8小时,那么只要将连接池内连接的生产周期设置得比...8小时短就行了。

3.7K20

Kubernetes 最佳实践:解决长连接服务扩容失效

在现网运营中,有很多场景为了提高效率,一般都采用建立长连接的方式来请求。我们发现在客户端以长连接请求服务端的场景下,K8S的自动扩容会失效。...对长连接扩容失效的问题,我们的解决方法是将长连接转换为短连接。...的 Header 头标记 “Connection:close”,通知客户端处理完当前的请求后关闭连接,新的请求需要重新建立TCP连接,所以这个过程中不会出现请求失败,同时又达到了将长连接按需转换为短连接的目的...通过这个办法客户端和云K8S服务端处理完一批请求后不断的更新TCP连接,自动扩容的新Pod能接收到新的连接请求,从而解决了自动扩容失效的问题。...() 获得计数值,判断达到阈值 1000 后在返回的 Header 中插入 “Connection:close” 通知客户端关闭连接,重新建立连接来发起请求。

3.6K61

众里寻她千百度,蓦然回首,那bug却在灯火阑珊处

首先这是一个无法重现的错误,无法重现的错误,通常是一个初始化问题,或者是与时间有关问题,这让人联想到了经典的mysql8小时重连问题: 当一个连接的空闲时间超过8小时后,MySQL 就会断开该连接,而dbcp...连接池则以为该被断开的连接依然有效。...如果此时客户端向dbcp连接池请求连接连接池就会把已经失效连接返回给客户端,客户端在使用该失效连接的时候即抛出异常。...还有一些问题从代码层就可以直接发现,但总少不了寻寻觅觅的过程,比如曾经碰到过一个拦截器失效问题。...bug被记录或可重现是调试工作成功的第一步,试想前面那两个例子,如果没有那行No operations allowed after connection closed,或者拦截器时而有效,时而失效,那调试工作将会难上十倍不止

1.3K90
领券