疯狂

STANDING ON THE SHOULDERS OF GIANTS
posts - 480, comments - 486, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

dbcp重连(转)

Posted on 2013-06-06 09:38 疯狂 阅读(4258) 评论(0)  编辑  收藏 所属分类: database方法论

转自:http://lc87624.iteye.com/blog/1734089

 

使用数据库连接池时,免不了会遇到断网、数据库挂掉等异常状况,当网络或数据库恢复时,若无法恢复连接池中的连接,那必然会是一场灾难。

关于dbcp的自动重连配置,网上相关的资料也不少,通过以下资料,并对照官方文档中的参数说明,大致能了解各项配置的含义,我就不冗诉了,本文的目的主要是对问题排查的经过做个简单的记录。
参考资料:

测试环境:
  • dbcp版本——1.4
  • 数据库——postgresSQL 9.10(简称pg)
  • 本地(以下称为client)操作系统及数据库服务器(以下称为server)操作系统均为linux
  • server位于内网环境,client需要通过vpn或网线直连内网才能访问数据库

首先模拟的是断网的情况
在本地测试dbcp的重连配置时,发现断网后,连接池无法重建连接,分别试过testOnBorrow和testWhileIdle两种validate方式,都没能解决,现象如下:
1. 正常启动应用,在server端通过"select * from pg_stat_activity"查看连接数,会有initialSize个来自client的IDLE连接。——正常
2. 在client端执行各种查询操作,连接数保持不变,且在server端的db log中能看到validate query。——正常
3. 手动切断vpn,client与server断开,查询无法返回结果;然后重连,再次查看连接数,连接数仍保持不变,且连接的创建时间为断网前,即是说连接池认为之前的连接仍然有效,没有销毁旧连接&创建新连接。
4. 此时在应用中执行各种查询操作,均无响应,等待一段时间后(分钟级),超时抛出异常:
Caused by: org.postgresql.util.PSQLException: An I/O error occured while sending to the backend.
Caused by: java.net.SocketException: Connection timed out.
5. 继续通过"select * from pg_stat_activity"查看连接数,隔一段时间后,连接消失。

问题:断网后,仍留在线程池内的连接是否有效?若有效,为什么网络恢复后查询无响应?若无效,为何线程池没有发现并重新创建有效连接?
排查过程:
1.重连vpn后,通过netstat查看client至server的连接
Java代码  
  1. sudo netstat -antop | grep :5432  | grep java  
注:5432为pg端口,grep java是为了过滤client上的其他形式的连接。
发现连接数和在server端看到的连接数一致,且均为ESTABLISH状态。
2. 但在client上执行查询时,通过tcpdump查看client发往server的tcp请求,并无任何请求产生。
Java代码  
  1. sudo tcpdump -s 65535 -X -i eth0 host xxx.xxx.xxx  
可见当前线程池中的连接实际上已经失效了,但dbcp仍认为它是有效的,因此仍在尝试用旧连接访问数据库,直至网络超时。

于是,开始怀疑是vpn的问题,将client接上网线直连内网后,再次重试上述步骤,只是把断网的方式由切断vpn换成了拔网线,发现这次使用断网前的连接能够正常访问数据库,于是断定是vpn的问题,猜测是重连vpn后,虽然client端ip没有变,但路由的路径已经变了,之前的连接无法复用,但dbcp并不知道。对网络细节不是太熟悉,就不多加揣测了。

接下来模拟数据库断开client连接的情况
由于pg采用的是进程模型,与数据库建立的每一个连接都是单独的一个进程,故尝试采用kill进程的方式模拟数据库断开连接。
预期的结果是:kill掉一个连接进程后,dbcp通过validate query发现该连接失效,将销毁该连接并重新创建新连接。
但实际情况确是:kill掉一个连接后,所有连接全部被销毁。
问题:究竟是数据库还是dbcp销毁了所有连接?
排查过程:
熟悉pg的同事认为pg之所以采用进程模型,就是为了避免连接之间的影响,因此不可能发生kill一个连接,其他连接也被销毁的情况。在这个理论前提下,问题就变得很诡异,因为dbcp的validate肯定是针对一个连接的,也不可能会在validate一个连接失效的情况下销毁所有连接,于是越想越偏,甚至开始怀疑是pg的jdbc driver有问题,最终放弃了深究。
但我总觉得有点不太对劲,于是推翻之前的前提,开始怀疑是pg销毁了所有连接。于是,在使用连接池的应用之外,通过pg的数据库客户端psql连接db,这就建立了一个与dbcp无关的连接,接着继续在server端kill了一个连接池中的连接,继而发现psql创建的连接也被销毁了,这就能确定是pg在销毁连接,因为dbcp不可能控制自身范围之外的连接。
后来才知道,pg之所以会这么做,是因为我们kill连接时使用的是kill -9(简称9杀),9杀太过粗暴,pg会重启很多内部进程,以保证所有进程正常,之前的连接也将会丢失,换用普通的kill命令,则不会发生以上情况。可见9杀很多情况下是十分危险的,试想一个线上db,若是9杀一个连接,后果不堪设想。。。

总结
说是dbcp问题排查,但大家可以看到最终问题的根源都跟dbcp没有什么关系。实际工作中的很多问题,关联的因素众多,需要有各方面的知识储备才能找到真正问题根源,否则就会把问题归结到一个自己不太了解的领域。
另外,看到dbcp基本配置和重连配置这篇文章中对连接池重连有两句不错的总结,引用一下:
引用
1. 数据库意外重启后,原先的数据库连接池能自动废弃老的无用的链接,建立新的数据库链接
2. 网络异常中断后,原先的建立的tcp链接,应该能进行自动切换


最后附上测试使用的dbcp配置。
testOnBorrow配置:
Xml代码  
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  
  2.         <property name="driverClassName" value="${jdbc.driver}" />  
  3.         <property name="url" value="${jdbc.url}"/>  
  4.         <property name="username" value="${jdbc.user}" />  
  5.         <property name="password" value="${jdbc.passwd}" />  
  6.         <property name="removeAbandoned" value="true"/>  
  7.           <property name="initialSize" value="10" />  
  8.           <property name="maxIdle" value="10" />  
  9.           <property name="minIdle" value="10" />  
  10.            <property name="maxActive" value="30" />  
  11.            <property name="maxWait" value="30000" />  
  12.            <property name"testWhileIdle" value="false" />  
  13.         <property name"testOnBorrow" value="true" />  
  14.         <property name"testOnReturn" value="false" />  
  15.         <property name"validationQuery" value="select 1" />  
  16.         <!-- <property name= "validationQueryTimeout" value="1" /> 配置已失效-->  
  17.     </bean>  
testWhileIdle配置:
Xml代码  
  1. <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">  
  2.         <property name="driverClassName" value="${jdbc.driver}" />  
  3.         <property name="url" value="${jdbc.url}"/>  
  4.         <property name="username" value="${jdbc.user}" />  
  5.         <property name="password" value="${jdbc.passwd}" />  
  6.         <property name="removeAbandoned" value="true"/>  
  7.           <property name="initialSize" value="10" />  
  8.           <property name="maxIdle" value="10" />  
  9.           <property name="minIdle" value="10" />  
  10.            <property name="maxActive" value="30" />  
  11.            <property name="maxWait" value="30000" />  
  12.            <property name"testWhileIdle" value="true" />  
  13.         <property name"testOnBorrow" value="false" />  
  14.         <property name"testOnReturn" value="false" />  
  15.         <property name"validationQuery" value="select 1" />  
  16.         <!-- <property name= "validationQueryTimeout" value="1" /> 配置已失效-->  
  17.         <property name"timeBetweenEvictionRunsMillis" value="30000" />  
  18.         <property name"numTestsPerEvictionRun" value="30" />  
  19.         <property name="minEvictableIdleTimeMillis" value="1800000" />  
  20.     </bean>  
注:testOnBorrow只会发现当前连接失效,再创建一个连接供当前查询使用,而testWhileIdle会定时校验numTestsPerEvictionRun个连接,只要发现连接失效,就将其移除再重新创建。

 


只有注册用户登录后才能发表评论。


网站导航: