druid Communications link failure报错处理

目录

现象

原因

druid的关键参数详解

解决方案

验证:

1, test-while-idle 为false情况

2, test-while-idle true,time-between-eviction-runs-millis<30

3,test-while-idle true,time-between-eviction-runs-millis>30

4,test-while-idle false,


现象

日志报错:com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

原因

从数据库连接池拿到了已经关闭的连接,导致报错。druid有定时任务进行空闲连接的检测和回收,当连接时长超过mysql的连接超时时间时,会被mysql强制断开,而如果此时数据库连接池并没有检测到连接已断开并交给应用去使用就会导致报错。

1、查看mysql服务器端的连接超时时间,单位秒,默认时8小时

show global variables like 'wait_timeout'

show global variables like 'interactive_timeout'

druid的关键参数详解

minIdle: 最小连接池数量

minEvictableIdleTimeMillis: 单位毫秒,默认30分钟,如果连接池中空闲连接大于minIdle数量,且连接空闲时间超过该值,则进行连接的回收操作。

maxEvictableIdleTimeMillis: 单位毫秒,默认7小时,如果连接空闲时间超过该值则强制关闭。

timeBetweenEvictionRunsMillis: 单位毫秒,两个作用:

1) Destroy线程会检测连接的间隔时间,如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接,连接时在取一条活跃的连接。

2) testWhileIdle的判断依据,详细看testWhileIdle属性的说明

testWhileIdle:默认值为false。 建议配置为true, 不影响性能,并且保证安全性。申请连接的时候检测,如果空闲时间大于timeBetweenEvictionRunsMillis,执行validationQuery检测连接是否有效。

validationQuery: 用来检测连接是否有效的sql,要求是一个查询语句,常用select 'x'。如果validationQuery为null,testOnBorrow、testOnReturn、testWhileIdle都不会起作用

解决方案

当以上参数配置不合理时,一般人错误原因应该是3

1)minEvictableIdleTimeMillis过大 空闲连接一直没有被回收,而超过mysql连接超时时间被强制回收后,则此时获取到的连接会导致报错。

2)timeBetweenEvictionRunsMillis配置过大,则在该时间窗口内获取到的连接可能报错。

3)maxEvictableIdleTimeMillis在某种情况下7小时未自动回收,导致8小时后数据库自动断开,建议改成3小时或更小。timeBetweenEvictionRunsMillis改成10000以便10秒检查一遍,testWhileIdle设置true 

验证:

数据库超时时间设为30s

set global wait_timeout=30;

1, test-while-idle 为false情况

条件:minEvictableIdleTimeMillis和maxEvictableIdleTimeMillis设置的足够大,test-while-idle设置为false

分析:执行第一次请求建立数据库连接,等待30s后执行第二次请求,此时连接已被数据库断开,因为连接池minEvictableIdleTimeMillis足够大,所以不会关闭空闲连接,且test-while-idle为false不会在请求时检测连接,所以预期会报错

      maxActive: 20   
      initialSize: 1      
      minIdle: 1       
      maxWait: 60000   
      time-between-eviction-runs-millis: 40000
      minEvictableIdleTimeMillis: 1800000
      maxEvictableIdleTimeMillis: 2400000
      validationQuery: SELECT 1
      test-while-idle: false  
      test-on-borrow: false 
      test-on-return: false 
 

 

2, test-while-idle true,time-between-eviction-runs-millis<30

条件:minEvictableIdleTimeMillis和maxEvictableIdleTimeMillis设置的足够大;

test-while-idle设置为true,time-between-eviction-runs-millis<30s

分析:执行第一次请求建立数据库连接,等待30s后执行第二次请求,此时连接已被数据库断开,因为连接池minEvictableIdleTimeMillis足够大,所以不会关闭空闲连接,test-while-idle为true会检测空闲超过time-between-eviction-runs-millis的连接,且time-between-eviction-runs-millis<30s, 等待30秒后进行第二次请求时会执行连接有效性检测抛弃无效连接,所以总是能拿到有效连接,不会报错。

      maxActive: 20   
      initialSize: 1      
      minIdle: 1       
      maxWait: 60000   
      time-between-eviction-runs-millis: 20000
      minEvictableIdleTimeMillis: 1800000
      maxEvictableIdleTimeMillis: 2400000
      validationQuery: SELECT 1
      test-while-idle: true  

可以看到第二次请求druid新建了一条连接而不是使用连接池已有的连接。

3,test-while-idle true,time-between-eviction-runs-millis>30

条件:minEvictableIdleTimeMillis和maxEvictableIdleTimeMillis设置的足够大;

test-while-idle设置为true,time-between-eviction-runs-millis>30s

分析:执行第一次请求建立数据库连接,等待30s以后执行第二次请求,此时连接已被数据库断开,因为连接池minEvictableIdleTimeMillis足够大,所以不会关闭空闲连接,test-while-idle为true会检测空闲超过time-between-eviction-runs-millis的连接,且time-between-eviction-runs-millis>30s, 分以下两种情况

      maxActive: 20   
      initialSize: 1      
      minIdle: 1       
      maxWait: 60000   
      time-between-eviction-runs-millis: 40000
      minEvictableIdleTimeMillis: 1800000
      maxEvictableIdleTimeMillis: 2400000
      validationQuery: SELECT 1
      test-while-idle: true  

1)等待30秒且小于40秒,由于此时空闲时间<time-between-eviction-runs-millis ,所以获取连接时不会执行有效性质检测,所以依然会报错

2)等待40秒后进行第二次请求时会执行连接有效性检测抛弃无效连接,所以总是能拿到有效连接,不会报错。

4,test-while-idle false,

minEvictableIdleTimeMillis设置为40,minIdle设置为0

      maxActive: 20   
      initialSize: 1      
      minIdle: 0       
      maxWait: 60000   
      time-between-eviction-runs-millis: 1000
      minEvictableIdleTimeMillis: 40000
      maxEvictableIdleTimeMillis: 2400000
      validationQuery: SELECT 1
      test-while-idle: true  

1)等待40秒执行第二次请求操作,则满足如果连接池中空闲连接大于minIdle数量,且连接空闲时间超过该值,则进行连接的回收操作,预期不会报错。

2)等待35秒执行第二次请求,则不满足空闲时间大于40秒,预期会报错

 5,其他情况:长事务,time-between-eviction-runs-millis过大,minEvictableIdleTimeMillis和maxEvictableIdleTimeMillis大于wait_timeout等

------------------------------------------与正文内容无关------------------------------------
如果觉的文章写对各位读者老爷们有帮助的话,麻烦点赞加关注呗!作者在这拜谢了!

混口饭吃了!如果你需要Java 、Python毕设、商务合作、技术交流、就业指导、技术支持度过试用期。请在关注私信我,本人看到一定马上回复!

  • 22
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
根据提供的引用内容,"druid Communications link failure"错误通常是由于与数据库之间的连接断开引起的。这可能是因为尝试使用一个已经断开的连接导致的。然而,根据Druid的连接检查功能,不应该出现这种情况。为了解决这个问题,我们可以了解一下Druid连接池的基本配置以及连接保活和回收机制。 Druid连接池是一个开源的Java连接池,它提供了一些高级功能来管理数据库连接。下面是一些关于Druid连接池的概述: 1. 配置Druid连接池:你可以通过配置文件或编程方式来配置Druid连接池。配置文件通常是一个.properties文件,你可以在其中指定数据库的URL、用户名、密码等信息。 2. 连接保活和回收机制:Druid连接池提供了一些机制来保持连接的活跃状态并回收不再使用的连接。其中包括心跳检测、空闲连接检测和连接超时设置等。 3. 连接检查功能:Druid连接池具有连接检查功能,可以在从连接池中获取连接之前检查连接的有效性。这可以帮助避免使用已经断开的连接。 为了解决"druid Communications link failure"错误,你可以尝试以下步骤: 1. 检查数据库的连接配置是否正确,包括URL、用户名和密码等信息。 2. 确保数据库服务器正常运行,并且网络连接没有问题。 3. 检查Druid连接池的配置文件或代码,确保连接池的配置正确。 4. 调整连接池的相关参数,例如心跳检测间隔、连接超时时间等,以适应你的应用需求。 5. 如果问题仍然存在,可以尝试升级Druid连接池的版本,或者考虑使用其他连接池实现。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

A乐神

恭喜发财啊,老板,嘻嘻!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值