解决数据库连接池连接mysql时,每隔8小时mysql自动断开连接的问题
Mysql 自动断开连接的问题及解决办法
Mysql 自动断开连接的问题及解决办法曾经在公司的时候,同事做项目(tomcat + struts+ mysql)时遇到了这样一个问题。
第一次登录的时候,系统正常运行,机器没有关闭,第二天再次登陆的时候,系统就出现了问题。
后来查出来是数据库连接池的连接断开的缘故。
重起tomcat 又恢复正常了。
原因是Mysql的把长时间没有活跃的连接给断开了。
默认的时间是28800s ,折8小时。
也不知道当时他有没有仔细上网搜索,反正,他问我,我也因为时间忙没有仔细探究。
后来他就索性放弃数据库连接池,直接用JDBC 代替了。
这几天,自己做的项目又遇到了这个问题,不得不设法解决这个问题。
终于有了解决办法,而且仍然可以使用数据库连接池。
核心思想就是改变数据库连接池的实现方式。
原先用的是struts自带的数据库连接池(struts-legacy.jar),改用apache 的dbcp连接池。
步骤如下:1,修改数据库连接池,使用apache的 DBCP代替从apache官方网站新增两个包 commons-pool-1.3.jar 和commons-dbcp-1.2.2.jar放到相应的lib下面。
如果已经有了,不需下载。
2,修改Struts-config.xml配置。
修改如下:<data-sources><data-sourcekey="org.apache.struts.action.DATA_SOURCE"type="mons.dbcp.BasicDat aSource"><set-property property="driverClassName"value="com.mysql.jdbc.Driver" /><set-property property="description"value="wjjg" /><set-property property="url"value="jdbc:mysql://localhost/wjjg?useUnicode=true&characterEncod ing=GB2312" /><set-property property="password" value="12345678" /><set-property property="username" value="wjjg" /><set-property property="maxActive" value="10" /> <set-property property="maxIdle" value="60000" /><set-property property="maxWait" value="60000" /><set-property property="defaultAutoCommit" value="true" /><set-property property="defaultReadOnly" value="false" /><set-property property="testOnBorrow" value="true"/><set-property property="validationQuery" value="select 1"/></data-source>其中testOnBorrow 和validationQuery 很重要。
MySQL连接中断和重连的处理方法
MySQL连接中断和重连的处理方法在进行数据库操作时,我们经常会遇到MySQL连接中断的情况。
当连接中断后,我们需要考虑如何快速恢复连接,以确保数据的完整性和一致性。
本文将介绍MySQL连接中断的原因及常见的处理方法,以帮助读者更好地应对这一问题。
一、连接中断的原因1. 网络故障:网络中断或网络信号不稳定是导致MySQL连接中断的最常见原因之一。
例如,当客户端和服务器之间的网络连接断开时,连接将被中断。
2. 服务器故障:服务器端可能会出现故障,例如服务器崩溃、内存不足或负载过高等,这些故障都可能导致连接中断。
3. 长时间无请求:当客户端在一段时间内没有向服务器发送请求时,MySQL 会自动断开连接。
这是为了避免占用过多的资源。
4. 防火墙限制:防火墙可能会阻止MySQL的连接请求,导致连接中断。
这通常发生在服务器部署在公司内部网络中,而客户端尝试从外部网络连接时。
二、处理方法1. 检查网络连接:当连接中断时,第一步是检查网络连接。
我们可以使用ping 命令检查客户端和服务器之间的网络连接是否正常。
如果发现网络故障,可以尝试重新连接网络或联系网络管理员解决问题。
2. 使用长连接:在MySQL中,可以使用长连接(persistent connection)来解决连接断开的问题。
长连接是指客户端与服务器之间保持连接的一个连接模式,连接在使用后不会主动断开,而是保持长时间的连接状态。
这样可以减少连接的建立和断开次数,提高应用的性能和稳定性。
在PHP中,可以使用mysqli或PDO等扩展来实现长连接。
3. 设置超时时间:MySQL客户端和服务器之间的连接通常有一个超时时间。
当连接超过该时间后,MySQL服务器会主动断开连接。
我们可以通过设置连接超时时间的方式来应对连接中断的问题。
可以通过修改MySQL配置文件中的"wait_timeout"参数来设置连接超时时间。
同时,也可以在连接MySQL时,通过设置相应的连接选项来指定超时时间。
mysql默认8小时连接断开机制解决
mysql默认8⼩时连接断开机制解决转载连接:/database/1639209.html本⽂提供了对c3p0与DBCP连接池连接MySql数据库时, 8⼩时内⽆请求⾃动断开连接的解决⽅案。
⾸先介绍⼀下我在项⽬(c3p0连接池)中遇到的问题,后⾯还提供了使⽤DBCP连接池的解决⽅案。
原因分析:MySQL服务器默认的“wait_timeout”是28800秒即8⼩时,意味着如果⼀个连接的空闲时间超过8个⼩时,MySQL将⾃动断开该连接,⽽连接池却认为该连接还是有效的(因为并未校验连接的有效性),当应⽤申请使⽤该连接时,就会导致上⾯的报错。
解决⽅案(解决这个问题的办法有三种,推荐第⼆种):1. 增加 MySQL 的 wait_timeout 属性的值修改mysql安装⽬录下的配置⽂件 my.ini⽂件(如果没有此⽂件,复制“my-default.ini”⽂件,⽣成“复件 my-default.ini”⽂件。
将“复件 my-default.ini”⽂件重命名成“my.ini” ),在⽂件中设置:wait_timeout=31536000interactive_timeout=31536000这两个参数的默认值是8⼩时(60*60*8=28800)。
注意: 1.wait_timeout的最⼤值只允许2147483 (24天左右)2.修改配置⽂件为⽹上⼤部分⽂章所提供的⽅式,也可以使⽤mysql命令对这两个属性进⾏修改2. 减少连接池内连接的⽣存周期减少连接池内连接的⽣存周期,使之⼩于上⼀项中所设置的wait_timeout 的值。
修改 c3p0 的配置⽂件,在 Spring 的配置⽂件中设置:<bean id="dataSource" class="boPooledDataSource"><property name="maxIdleTime"value="1800"/><!--other properties --></bean>3. 定期使⽤连接池内的连接定期使⽤连接池内的连接,使得它们不会因为闲置超时⽽被 MySQL 断开。
MySQL数据库连接断开与重连处理方法
MySQL数据库连接断开与重连处理方法MySQL是一种常用的关系型数据库管理系统,广泛应用于各种网站和应用程序中。
然而,由于网络不稳定性或其他原因,数据库连接有时会断开,这会给程序的正常运行带来困扰。
本文将分享一些处理MySQL数据库连接断开和重连的方法,帮助程序员更好地应对这个问题。
一、了解MySQL连接状态在处理MySQL连接断开和重连之前,首先需要了解MySQL连接状态。
当一个连接建立后,MySQL服务器会为该连接分配一个唯一的标识符(称为连接ID),并保持与客户端的通信。
但是,由于网络原因或服务器的配置,连接可能会断开。
当连接断开时,客户端会收到一个“MySQL服务器断开连接”的错误信息。
二、处理连接断开的方法1. 设置MySQL连接超时时间MySQL服务器默认的连接超时时间为28800秒(8小时),即如果一个连接在8小时内没有任何活动,服务器会自动断开该连接。
这个时间对于大多数应用程序来说是足够长的,但是对于一些特殊应用场景来说可能不够。
可以通过修改MySQL服务器的配置文件,将连接超时时间调整为更合适的值。
需要注意的是,将超时时间设置得过短可能导致频繁的连接重连,增加服务器的负担。
2. 使用心跳机制心跳机制是一种常用的处理连接断开的方法。
它的原理是在建立连接后,定期向MySQL服务器发送一个空的查询,以保持连接的活跃状态。
如果服务器在一段时间内没有收到任何查询请求,就会主动断开连接。
通过设置适当的心跳间隔,可以有效地防止连接断开。
3. 检测连接状态在程序中,可以通过调用MySQL提供的API函数来检测连接的状态。
如果连接断开,可以通过重新建立连接来恢复。
一种常用的检测方法是使用`ping()`函数,该函数会向服务器发送一个简单的查询,如果连接断开,会返回一个错误信息。
在捕获到连接断开的错误后,可以进行相应的处理,如重新连接或重启程序。
4. 使用连接池连接池是一种常见的处理连接断开和重连的方法。
MySQL8小时连接超时断开问题
使用Connector/J连接MySQL数据库,程序运行较长时间后就会报以下错误:
Communications link failure,The last packet successfully received from the server was *** millisecond ago.The last packet successfully sent to the server was *** millisecond ago。
其中错误还会提示你修改wait_timeout或是使用Connector/J的autoReconnect属性避免该错误。
后来查了一些资料,才发现遇到这个问题的人还真不少,大部分都是使用连接池方式时才会出现这个问题,短连接应该很难出现这个问题。
这个问题的原因:
MySQL服务器默认的“wait_timeout”是28800秒即8小时,意味着如果一个连接的空闲时间超过8个小时,MySQL将自动断开该连接,而连接池却认为该连接还是有效的(因为并未校验连接的有效性),当应用申请使用该连接时,就会导致上面的报错。
1.按照错误的提示,可以在JDBC URL中使用autoReconnect属性,实际测试时使用了
autoReconnect=true&failOverReadOnly=false,不过并未起作用,使用的是5.1版本,可能真像网上所说的只对4之前的版本有效。
2.没办法,只能修改MySQL的参数了,wait_timeout最大为31536000即1年,在f中加入:
[mysqld]
wait_timeout=31536000
interactive_timeout=31536000
重启生效,需要同时修改这两个参数。
mysql八小时问题
mysql⼋⼩时问题 最近买了阿⾥云,把项⽬部署上去以后,每天第⼀次访问总是出⼀次异常,然后刷新⼀下就正常了。
经查询资料发现,原来mysql默认会⾃动关闭空闲时间超过8⼩时的连接,⽽连接池并不知道这个连接已经关闭了,所以就会出异常。
查看mysqlSHOW GLOBAL VARIABLES LIKE'wait_timeout'; 修改wait_timeout,虽然通过修改mysql的wait_timeout值可以解决问题,但实际情况中这样修改会影响到所有的项⽬,并不推荐这样做SET GLOBAL wait_timeout=60; 我⽤的是dpcp连接池,配置⽂件⾥加⼊以下内容,意思是每隔timeBetweenEvictionRunsMillis毫秒检测⼀次空闲时间超过minEvictableIdleTimeMillis毫秒的连接,检测到就重连⼀次。
根据这个原理,可以计算出只要这两个参数加起来⼩于wait_timeout即可,例如下⾯每隔两⼩时检测空闲超过五⼩时的连接,则空闲连接最多也会在第七个⼩时的时候被检测到并重连,⽽mysql默认是⼋⼩时,这样就解决了问题。
注意这两个参数的单位都是毫秒,⽽mysql中wait_timeout的单位是秒。
<!-- 8⼩时问题,每隔两⼩时检测空闲超过五⼩时的连接 --><property name="timeBetweenEvictionRunsMillis" value="7200000"/><property name="minEvictableIdleTimeMillis" value="18000000"/> 原创⽂章,转载请注明出处。
如何解决mysql数据库8小时无连接自动关闭
SELECT CURRENT_USER
专家建议关于mysql自动关闭服务的三个方法,用户最好采取第一个办法最为彻底解决。
方法二:修改如下JDBC连接的 URL:
jdbc:mysql://hostaddress:3306/schemaname?autoReconnect=true
添加 autoReconnect=true 这个参数,即能解决这个问题。
方法三:配置文件(proxool.xml):
方法一:这个参数的名称是 wait_timeout,其默认值为 28800秒(8小时)。其意义为关闭一个连接之前在这个连接上等到行动的秒数,也就是说,如果一个连接闲置超过这个选项所设置的秒数,MySQL 会主动断开这个连接。
修改操作:
linux下打开/etc/f,在属性组mysqld下面添加参数如下:
mysql
jdbc:mysql://localhost/yourDatebase?useUnicode=true&characterEncoding=UTF-8
com.mysql.jdbc.Driver
90000
20
3
20
3
true
true
[mysqld]
interactive_timeout=28800000
wait_timeout=28800000
windows下打开my.ini,增加:
[mysqld]
interactive_timeout=28800000
wait_timeout=28800000
有实践表明,没有办法把这个值设置成无限大,即永久。因此如果你无法保证你的应用程序必定在设定的秒数内至少有一次操作,那么最好现象,可以通过mysql服务器端程序mysql Administrator调整连接参数。将max_connections max_updates max_questions三项数据调整到很大的数字,那么你有限的操作将不会导致数据库服务的终止了在MySQL数据库中,如果一个连接8小时没有请求和操作,就会自动断开,从而导致一些基于数据库连接的应用程序,特别是 WEB 应用程序出错。解决mysql数据库自动关闭服务三个方法:
MySQL+Hibernate下连接空闲8小时自动断开问题解决方案
MySQL+Hibernate下连接空闲8小时自动断开问题解决方案前段时间刚完成一个家教网项目,数据库为MySQL5.0,持久层使用Hibernate 3.1,没有使用额外的连接池,那么Hibernate会默认使用它自带的一个默认连接池,也就是DriverManagerConnectionProvider。
先在本机上调试都毫无问题,于是部署到服务器上,也都没什么问题。
由于这是新网站,根本还没正式对外发布和宣传,所以头两天根本没人访问。
等到第二天,我再次访问网站时,问题就出现了,错误信息如下:javax.servlet.ServletException: org.hibernate.exception.JDBCConnectionException: could not execute queryorg.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)javax.servlet.http.HttpServlet.service(HttpServlet.java:690)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jsp.index_jsp._jspService(index_jsp.java:57)org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30)org.hibernate.exception.JDBCConnectionException: could not execute queryorg.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:74)org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)org.hibernate.loader.Loader.doList(Loader.java:2148)org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)org.hibernate.loader.Loader.list(Loader.java:2024)org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)org.hibernate.impl.SessionImpl.list(SessionImpl.java:1533)org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)b1000.jcom.dao.ArticleDAO.getArticlesUnder(ArticleDAO.java:163)b1000.jcom.struts.action.HomeAction.execute(HomeAction.java:40)org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)javax.servlet.http.HttpServlet.service(HttpServlet.java:690)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jsp.index_jsp._jspService(index_jsp.java:57)org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30)com.mysql.jdbc.exceptions.MySQLNonTransientConnectionException: No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:** BEGIN NESTED EXCEPTION **municationsExceptionMESSAGE: Communications link failure due to underlying exception:** BEGIN NESTED EXCEPTION **java.io.EOFExceptionSTACKTRACE:java.io.EOFExceptionat com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1963)at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2375)at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2874)at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)at com.mysql.jdbc.Connection.execSQL(Connection.java:3249)at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1268)at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1403)at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)at org.hibernate.loader.Loader.doQuery(Loader.java:662)at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)at org.hibernate.loader.Loader.doList(Loader.java:2145)at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)at org.hibernate.loader.Loader.list(Loader.java:2024)at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1533)at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)at b1000.jcom.dao.ArticleDAO.getArticlesUnder(ArticleDAO.java:163)at b1000.jcom.struts.action.HomeAction.execute(HomeAction.java:40)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)atorg.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)at org.apache.jsp.index_jsp._jspService(index_jsp.java:57)at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30) atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.StandardWrapperV alve.invoke(StandardWrapperValve.java:233)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)at mon.HandlerRequest.invoke(HandlerRequest.java:283)at mon.ChannelSocket.invoke(ChannelSocket.java:767)at mon.ChannelSocket.processConnection(ChannelSocket.java:697)at mon.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)at ng.Thread.run(Unknown Source)** END NESTED EXCEPTION **Last packet sent to the server was 15 ms ago.STACKTRACE:municationsException: Communications link failure due to underlying exception:** BEGIN NESTED EXCEPTION **java.io.EOFExceptionSTACKTRACE:java.io.EOFExceptionat com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1963)at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2375)at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2874)at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)at com.mysql.jdbc.Connection.execSQL(Connection.java:3249)at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1268)at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1403)at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)at org.hibernate.loader.Loader.doQuery(Loader.java:662)at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)at org.hibernate.loader.Loader.doList(Loader.java:2145)at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)at org.hibernate.loader.Loader.list(Loader.java:2024)at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1533)at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)at b1000.jcom.dao.ArticleDAO.getArticlesUnder(ArticleDAO.java:163)at b1000.jcom.struts.action.HomeAction.execute(HomeAction.java:40)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)atorg.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)at org.apache.jsp.index_jsp._jspService(index_jsp.java:57)at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30) atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.StandardWrapperV alve.invoke(StandardWrapperValve.java:233)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)at mon.HandlerRequest.invoke(HandlerRequest.java:283)at mon.ChannelSocket.invoke(ChannelSocket.java:767)at mon.ChannelSocket.processConnection(ChannelSocket.java:697)at mon.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)at ng.Thread.run(Unknown Source)** END NESTED EXCEPTION **Last packet sent to the server was 15 ms ago.at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2586)at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2874)at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)at com.mysql.jdbc.Connection.execSQL(Connection.java:3249)at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1268)at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1403)at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)at org.hibernate.loader.Loader.doQuery(Loader.java:662)at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)at org.hibernate.loader.Loader.doList(Loader.java:2145)at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)at org.hibernate.loader.Loader.list(Loader.java:2024)at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1533)at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)at b1000.jcom.dao.ArticleDAO.getArticlesUnder(ArticleDAO.java:163)at b1000.jcom.struts.action.HomeAction.execute(HomeAction.java:40)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)atorg.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)at org.apache.jsp.index_jsp._jspService(index_jsp.java:57)at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30) atorg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)at org.apache.catalina.core.StandardWrapperV alve.invoke(StandardWrapperValve.java:233)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)at mon.HandlerRequest.invoke(HandlerRequest.java:283)at mon.ChannelSocket.invoke(ChannelSocket.java:767)at mon.ChannelSocket.processConnection(ChannelSocket.java:697)at mon.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)at ng.Thread.run(Unknown Source)** END NESTED EXCEPTION **com.mysql.jdbc.SQLError.createSQLException(SQLError.java:888)com.mysql.jdbc.Connection.checkClosed(Connection.java:1931)com.mysql.jdbc.Connection.prepareStatement(Connection.java:4705)com.mysql.jdbc.Connection.prepareStatement(Connection.java:4671)org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442)org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)org.hibernate.loader.Loader.doQuery(Loader.java:661)org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)org.hibernate.loader.Loader.doList(Loader.java:2145)org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)org.hibernate.loader.Loader.list(Loader.java:2024)org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)org.hibernate.impl.SessionImpl.list(SessionImpl.java:1533)org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)b1000.jcom.dao.ArticleDAO.getArticlesUnder(ArticleDAO.java:163)b1000.jcom.struts.action.HomeAction.execute(HomeAction.java:40)org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)javax.servlet.http.HttpServlet.service(HttpServlet.java:690)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jsp.index_jsp._jspService(index_jsp.java:57)org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337)org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)javax.servlet.http.HttpServlet.service(HttpServlet.java:803)b1000.jcom.system.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:30) 当时也搞不清楚为什么,但重启Tomcat后就一切回复正常了,但是又过了一天,问题再次出现。
mysql连接的空闲时间超过8小时后MySQL自动断开该连接解决方案
mysql连接的空闲时间超过8⼩时后MySQL⾃动断开该连接解决⽅案解决这个问题的办法有三种:修改 /etc/mysql/f⽂件,在 [mysqld] 节中设置:# Set a connection to wait 8hours in idle status.wait_timeout =86400相关参数,红⾊部分mysql> show variables like '%timeout%';+--------------------------+-------+| Variable_name | Value |+--------------------------+-------+| connect_timeout | 5 || delayed_insert_timeout | 300 || innodb_lock_wait_timeout | 50 || interactive_timeout | 28800 || net_read_timeout | 30 || net_write_timeout | 60 || slave_net_timeout | 3600 || wait_timeout | 28800 |+--------------------------+-------+同⼀时间,这两个参数只有⼀个起作⽤。
到底是哪个参数起作⽤,和⽤户连接时指定的连接参数相关,缺省情况下是使⽤wait_timeout。
我建议是将这两个参数都修改,以免引起不必要的⿇烦。
这两个参数的默认值是8⼩时(60*60*8=28800)。
我测试过将这两个参数改为0,结果出⼈意料,系统⾃动将这个值设置为。
换句话说,不能将该值设置为永久。
将这2个参数设置为24⼩时(60*60*24=604800)即可。
set interactive_timeout=604800;set wait_timeout=604800;修改 c3p0 的配置⽂件,设置:# How long to keep unused connections around(in seconds)# Note: MySQL times out idle connections after 8hours(28,800seconds)# so ensure this value is below MySQL idle timeoutcpool.maxIdleTime=25200在 Spring 的配置⽂件中:复制代码代码如下:<bean id="dataSource"class="boPooledDataSource"><property name="maxIdleTime"value="${cpool.maxIdleTime}"/><!--other properties --></bean>修改 c3p0 的配置⽂件,设置:# Prevent MySQL raise exception after a long idle timecpool.preferredTestQuery='SELECT1'cpool.idleConnectionTestPeriod=18000cpool.testConnectionOnCheckout=true修改 Spring 的配置⽂件:复制代码代码如下:<bean id="dataSource" class="boPooledDataSource"><property name="preferredTestQuery" value="${cpool.preferredTestQuery}"/><property name="idleConnectionTestPeriod" value="${cpool.idleConnectionTestPeriod}"/><property name="testConnectionOnCheckout" value="${cpool.testConnectionOnCheckout}"/><!--other properties --></bean>。
解决JDBC连接Mysql长时间无动作连接失效的问题
解决JDBC连接Mysql长时间⽆动作连接失效的问题错误场景介绍做的有⼀个项⽬使⽤JDBC⼿动创建Connection实现了⼀个简单的⾃定义数据库连接池,⽤来⽀持Canal解析数据库Binlog指定业务库的插⼊修改SQL来进⾏数据库分表备份(按照⽉份)操作.但是发现当⼀个⼀段时间(较长)没有进⾏数据库操作时,连接都失效了,导致SQL执⾏失败失效提⽰为No operations allowed after connection closed查明原因经过搜索发现这个问题是由于Mysql默认⼀个已创建的长连接28800秒(⼋⼩时)内没有任何动作则会断开连接,该值对应参数为wait_timeout.当超时时间内有执⾏动作则会重新计时查验查询Mysql超时连接时长命令show global variables like'wait_timeout'查看当前设置的超时断开连接时长.将其改为10,本地服务运⾏功能发现重现了No operations allowed after connection closed错误,即确实是连接超时失效解决⽅法1. 修改Mysql配置该⽅法不能根治这个问题,因为不能确认服务空闲时长⽽精确设置timeout并且还会造成多余连接长时间未断开⽽影响性能,所以不建议使⽤.建议在代码层⾯进⾏解决通过set global wait_timeout=time(秒)来修改最长连接等待超时时间,但是这样设置当Mysql重启失效可以通过修改my.ini⽂件永久改动超时时间,如下配置interactive_timeout=28800000wait_timeout=288000002. 连接丢弃重新创建连接使⽤conn.isValid(int timeout)(秒)判断是否失效返回true表⽰连接有效,返回false表⽰连接失效.当失效时则重新获取⼀个数据库连接即可,之前的对象由于引⽤丢失会被回收掉.3. 增加⾃动重连选项在URL最后添加autoReconnect=true参数,jdbc:mysql://hostaddress:3306/xhb?autoReconnect=true.我这⾥对这个没有效果,可能是对框架连接池有⽤.4. 定时执⾏⼀个动作进⾏超时时间刷新⽐如默认时间是⼋⼩时,则每七⼩时对连接执⾏⼀次select 1语句来刷新该连接在数据库的超时等待时长也可以1 2 4⼀起使⽤,来防⽌突然⼀个流量静默期间后突发流量⾼峰⽽导致获取连接不及时补充:连接总是被mysql回收_⼀般连接池是怎么处理mysql⾃动回收长时间若⼲套 MySQL 环境,只有⼀套:⾏为异常,e5a48de588b63231313335323631343130323136353331333436316239怀疑触发 bug性能异常,⽐其他环境都要低在这种场景下,我们⼀般的做法是⾸先控制变量,查看软硬件配置,以及 MySQL 的参数配置。
关于MySQL的wait_timeout连接超时问题报错解决实施方案
关于MySQL的wait_timeout连接超时问题报错解决方案————————————————————————————————作者:————————————————————————————————日期:2关于MySQL的wait_timeout连接超时问题报错解决方案Mysql服务器默认的“wait_timeout”是8小时【也就是默认的值默认是28800秒】,也就是说一个connection空闲超过8个小时,Mysql将自动断开该connection,通俗的讲就是一个连接在8小时内没有活动,就会自动断开该连接。
wait timeout的值可以设定,但最多只能是2147483,不能再大了。
也就是约24.85天所以即使你MySQL通过my.ini 在# The TCP/IP Port the MySQL Server will listen onport=3306下面添加# this is myown dinifition for mysql connection timeoutwait_timeout=31536000interactive_timeout=31536000无论超过最大限度多大的数值,只能被MySQL解析为2147483,2147483天后你的程序该出什么错还是什么错,避免不了的在说这个错误之前先说明我的项目是通过Hibernate来进行数据库操作的关于MySQL连接超时问题,估计很多人都遇到过:大致情形都是这样,开发测试时程序都是正常的,一到第二天就出先莫名错误,比如在我的项目中就是定时任务执行,每天凌晨一点执行一次,也就是24小时每隔24小时执行,远远超出了8小时如果你刚好在数据库超时的第一时间内看到日志记录的话那么,第一次超时发生的错误就是这样的:ERROR [org.hibernate.util.JDBCExceptionReporter] - Communications link failureLast packet sent to the server was 0 ms ago.如果不是第一次超时后执行,以后每次报错就变成嵌套的错误了,就是下面这样:ERROR [org.hibernate.util.JDBCExceptionReporter] -No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:** BEGIN NESTED EXCEPTION **municationsExceptionMESSAGE: The last packet successfully received from the server was86395 milliseconds ago.The last packet sent successfully to the server was 86395 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the serverconfigured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. STACKTRACE:municationsException: The last packet successfully received from the server was86395 milliseconds ago.The last packet sent successfully to the server was 86395 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property'autoReconnect=true' to avoid this problem.at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)atsun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)at ng.reflect.Constructor.newInstance(Unknown Source)at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)atcom.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1 074)at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3270)at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1932)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)atcom.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.ja va:1761)atcom.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java: 1912)atorg.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java: 208)at org.hibernate.loader.Loader.getResultSet(Loader.java:1812)at org.hibernate.loader.Loader.doQuery(Loader.java:697)atorg.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Lo ader.java:259)at org.hibernate.loader.Loader.doList(Loader.java:2232)atorg.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)at org.hibernate.loader.Loader.list(Loader.java:2124)at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401) atorg.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.ja va:363)atorg.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java :196)at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1149)at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)atorg.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.j ava:835)at.util.db.TargetRecordDaoImpl.findbyIdAndDate(TargetRecordDaoImp l.java:23)at .util.parser.ExcelOperate.readExcel(ExcelOperate.java:324) at .util.parser.ExcelParser.parser(ExcelParser.java:41)at.util.timer.CRMExcelParserTarger.execute(CRMExcelParserTarger.j ava:76)at org.quartz.core.JobRunShell.run(JobRunShell.java:199)atorg.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.j ava:549)Caused by: .SocketException: Software caused connection abort: socket write errorat .SocketOutputStream.socketWrite0(Native Method)at .SocketOutputStream.socketWrite(Unknown Source)at .SocketOutputStream.write(Unknown Source)at java.io.BufferedOutputStream.flushBuffer(Unknown Source)at java.io.BufferedOutputStream.flush(Unknown Source)at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3251)... 24 more** END NESTED EXCEPTION **具体解释是这样的:Mysql服务器默认的“wait_timeout”是8小时【也就是默认的值默认是28800秒】,也就是说一个connection空闲超过8个小时,Mysql 将自动断开该connection,通俗的讲就是一个连接在8小时内没有活动,就会自动断开该连接。
MySQL Hibernate下连接空闲8小时自动断开问题解决方案
MySQL+Hibernate下连接空闲8小时自动断开问题解决方案前段时间刚完成一个项目,数据库为MySQL5.0,持久层使用Hibernate3.2,没有使用额外的连接池,那么Hibernate会默认使用它自带的一个默认连接池,也就是DriverManagerConnectionProvider。
问题是待机一晚上后,第二天早上第一次登录总是失败。
察看日志发现如下错误:“com.mysql.jdbc.exceptions.jdbcmunicationsException: Communications link failureLast packet sent to the server was 0 ms ago.”经过一番调研,发现很多人都碰到过类似问题,但网上令人满意的回答并不多。
mysql网站上的提问也很多,但并没有正确答案;百度知道上倒是有一个近似正确的回答。
现将本人的解决办法总结一下:当时也搞不清楚为什么,但重启Tomcat后就一切回复正常了,但是又过了一天,问题再次出现。
仔细分析错误信息,问题肯定出在数据库连接部分,在网上查阅大量信息后,明确了问题的原因:MySQL 对所有连接的有效时间默认为28800秒,正好8小时,也就是说,如果一个连接8小时没有请求和操作,就会自动断开;但是对于Hibernate来说,它的连接池并不知道它所管理的连接中是否有被MySQL断开的。
如果一个程序要使用数据库连接,而Hibernte的连接池分配一个已经被MySQL断开了的给程序使用,那么便会出现错误。
为了证实确实是这个错误,我在本机上做了如下测试:首先启动Tomcat,网站能够正常打开;然后修改系统时间,往后调1天;然后再打开网站,同样的问题果然出现!MySQL + Hibernate架构相当普遍,所以这个问题也相当普遍,若读者也有这样的项目,建议做一下同样的测试,看看是否存在此问题!问题找到了,怎么解决呢?——思路1:增大MySQL的连接有效时间;上述问题是由mysql5数据库的配置引起的。
解决mysql服务器在无操作超时主动断开连接的情况
解决mysql服务器在⽆操作超时主动断开连接的情况我们在使⽤mysql服务的时候,正常情况下,mysql的设置的timeout是8个⼩时(28800秒),也就是说,如果⼀个连接8个⼩时都没有操作,那么mysql会主动的断开连接,当这个连接再次尝试查询的时候就会报个”MySQL server has gone away”的误,但是有时候,由于mysql服务器那边做了⼀些设置,很多情况下会缩短这个连接timeout时长以保证更多的连接可⽤。
有时候设置得⽐较变态,很短,30秒,这样就需要客户端这边做⼀些操作来保证不要让mysql主动来断开。
查看mysql的timeout使⽤客户端⼯具或者Mysql命令⾏⼯具输⼊show global variables like '%timeout%';就会显⽰与timeout相关的属性,这⾥我⽤docker模拟了⼀个测试环境。
mysql> show variables like '%timeout%';+-----------------------------+----------+| Variable_name | Value |+-----------------------------+----------+| connect_timeout | 10 || delayed_insert_timeout | 300 || have_statement_timeout | YES || innodb_flush_log_at_timeout | 1 || innodb_lock_wait_timeout | 50 || innodb_rollback_on_timeout | OFF || interactive_timeout | 30 || lock_wait_timeout | 31536000 || net_read_timeout | 30 || net_write_timeout | 60 || rpl_stop_slave_timeout | 31536000 || slave_net_timeout | 60 || wait_timeout | 30 |+-----------------------------+----------+13 rows in setwait_timeout:服务器关闭⾮交互连接之前等待活动的秒数,就是你在你的项⽬中进⾏程序调⽤interactive_timeout: 服务器关闭交互式连接前等待活动的秒数,就是你在你的本机上打开mysql的客户端,cmd的那种使⽤pymysql进⾏查询我在数据库⾥随便创建了⼀个表,插⼊两条数据mysql> select * from person;+----+------+-----+| id | name | age |+----+------+-----+| 1 | yang | 18 || 2 | fan | 16 |+----+------+-----+2 rows in set我使⽤pymysql这个库对其进⾏查询操作,很简单#coding:utf-8import pymysqldef mytest():connection = pymysql.connect(host='localhost',port=3306,user='root',password='123456',db='mytest',charset='utf8')cursor = connection.cursor()cursor.execute("select * from person")data = cursor.fetchall()cursor.close()for i in data:print(i)cursor.close()connection.close()if __name__ == '__main__':mytest()可以正确的得到结果(1, 'yang', 18)(2, 'fan', 16)连接超时以后的查询上⾯可以正常得到结果是由于当创建好⼀个链接以后,就⽴刻进⾏了查询,此时还没有超过它的超时时间,如果我sleep⼀段时间,看看什么效果。
关于MySQL的wait_timeout连接超时问题报错解决方案
关于MySQL的wait_timeout连接超时问题报错解决方案Mysql服务器默认的“wait_timeout”是8小时【也就是默认的值默认是28800秒】,也就是说一个connection空闲超过8个小时,Mysql将自动断开该connection,通俗的讲就是一个连接在8小时内没有活动,就会自动断开该连接。
wait timeout的值可以设定,但最多只能是2147483,不能再大了。
也就是约24.85天所以即使你MySQL通过my.ini 在# The TCP/IP Port the MySQL Server will listen onport=3306下面添加# this is myown dinifition for mysql connection timeoutwait_timeout=31536000interactive_timeout=31536000无论超过最大限度多大的数值,只能被MySQL解析为2147483,2147483天后你的程序该出什么错还是什么错,避免不了的在说这个错误之前先说明我的项目是通过Hibernate来进行数据库操作的关于MySQL连接超时问题,估计很多人都遇到过:大致情形都是这样,开发测试时程序都是正常的,一到第二天就出先莫名错误,比如在我的项目中就是定时任务执行,每天凌晨一点执行一次,也就是24小时每隔24小时执行,远远超出了8小时如果你刚好在数据库超时的第一时间内看到日志记录的话那么,第一次超时发生的错误就是这样的:ERROR [org.hibernate.util.JDBCExceptionReporter] - Communications link failureLast packet sent to the server was 0 ms ago.如果不是第一次超时后执行,以后每次报错就变成嵌套的错误了,就是下面这样:ERROR [org.hibernate.util.JDBCExceptionReporter] -No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:** BEGIN NESTED EXCEPTION **municationsExceptionMESSAGE: The last packet successfully received from the server was86395 milliseconds ago.The last packet sent successfully to the server was 86395 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the serverconfigured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. STACKTRACE:municationsException: The last packet successfully received from the server was86395 milliseconds ago.The last packet sent successfully to the server was 86395 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property'autoReconnect=true' to avoid this problem.at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)at ng.reflect.Constructor.newInstance(Unknown Source)at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)atcom.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1 074)at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3270)at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1932)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)atcom.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.ja va:1761)atcom.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java: 1912)atorg.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java: 208)at org.hibernate.loader.Loader.getResultSet(Loader.java:1812)at org.hibernate.loader.Loader.doQuery(Loader.java:697)atorg.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Lo ader.java:259)at org.hibernate.loader.Loader.doList(Loader.java:2232)at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129) at org.hibernate.loader.Loader.list(Loader.java:2124)at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401)atorg.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.ja va:363)atorg.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java :196)at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1149)at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)atorg.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.j ava:835)at.util.db.TargetRecordDaoImpl.findbyIdAndDate(TargetRecordDaoImp l.java:23)at .util.parser.ExcelOperate.readExcel(ExcelOperate.java:324) at .util.parser.ExcelParser.parser(ExcelParser.java:41)at.util.timer.CRMExcelParserTarger.execute(CRMExcelParserTarger.j ava:76)at org.quartz.core.JobRunShell.run(JobRunShell.java:199)atorg.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.j ava:549)Caused by: .SocketException: Software caused connection abort: socket write errorat .SocketOutputStream.socketWrite0(Native Method)at .SocketOutputStream.socketWrite(Unknown Source)at .SocketOutputStream.write(Unknown Source)at java.io.BufferedOutputStream.flushBuffer(Unknown Source)at java.io.BufferedOutputStream.flush(Unknown Source)at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3251)... 24 more** END NESTED EXCEPTION **具体解释是这样的:Mysql服务器默认的“wait_timeout”是8小时【也就是默认的值默认是28800秒】,也就是说一个connection空闲超过8个小时,Mysql 将自动断开该connection,通俗的讲就是一个连接在8小时内没有活动,就会自动断开该连接。
MySQL数据库连接超时(Wait_timeout)问题总结
MySQL数据库连接超时(Wait_timeout)问题总结第一篇:MySQL数据库连接超时(Wait_timeout)问题总结当应用程序和数据库建立连接时,如果超过了8个小时,应用程序不去访问数据库,数据库就会出现断掉连接的现象。
这时再次访问就会抛出异常.一般的解决方法大多是在数据库连接字符串中增加“autoReconnect=true ”选项。
但是这只对mysql4以前的版本有效。
在最新的mysql中是无效的。
其实要解决这个问题也有一个简单的方法,就是修改mysql的启动参数。
缺省情况下mysql的timeout 时间是28800秒,正好是8小时,增加一个0就可以了。
决定从根源入手,设置mysql的wait_timeout为31536000(一年),再来试试。
set-variable=wait_timeout=31536000 set-variable=interactive_timeout=31536000 问题得到了解决想了深入解一下mysql的工作原理百度了一下Google发现很多人都出现过这种问题,大多是配置hibernate时候出的问题,可惜我的项目中没有使用到hibernate只是简单的自己配了一个连接池,所以综合了问题的关键所在改了一下数据库配置,在这里暂且记录一下,以后备用。
Mysql服务器默认的“wait_timeout”是8小时,也就是说一个connection空闲超过8个小时,Mysql将自动断开该connection。
这就是问题的所在。
最近碰到了这个问题,检查后发现数据库连接池中保存的连接超时后失效了,下面是官方的解释 mysql gone-away从Mysql 5.x的某个版本之后,MySQL的自动关闭空闲连接的特性被修改了,假如一个连接空闲到超时时间(默认28000秒8小时),再次发起的Reconnect重新连接请求不会被接受,需要重新建立新连接,这就导致了SER的重连机制不能正常工作:SER只会在需要操作数据库时去使用同一个连接接口,断开了则发起重新连接请求,而且这个问题短期内SER也不能够解决。
MySQL参数autoReconnect=true解决8小时连接失效(转)
MySQL参数autoReconnect=true解决8⼩时连接失效(转)1. 即使在创建Mysql时url中加⼊了autoReconnect=true参数,⼀但这个连接两次访问数据库的时间超出了服务器端wait_timeout的时间限制,还是会CommunicationsException: The last packet successfully received from the server was xxx milliseconds ago.2. 服务器端的参数可以⽤show global variables like 'wait_timeout';set global wait_timeout=10;来进⾏设置,但是wait_timeout值不应该设的太⾼.3. 较好的策略是对处于idle状态的connection定时发送⼀个sql,来刷新服务器上的时间戳.这可以使⽤c3p0r的连接池.4. 对于tomcat的server.xml中使⽤的连接池,4.1 设置validationQuery,这样每次borrow(默认为开启)时会通过这个sql校验连接的有效性,但是增加了时间.4.2 设置timeBetweenEvictionRunsMillis="10000" minEvictableIdleTimeMillis="10000" 依赖evictor thread线程来把超时的连接关闭.4.3 设置testWhileIdle="true" timeBetweenEvictionRunsMillis="10000" validationQuery="select 1" 使得定时去⽤query检测处于idle状态的连接,也就刷新了服务器端的时间.5.每次提交的最⼤packet⼤⼩show global variables like 'max_allowed_packet';set global max_allowed_packet=1024*1024;6. SQLyog 中连接参数的设置6.1 在SQLyog中的设置 set autocommit=0,这样当前连接的⾃动提交为false,可以控制事务了.6.2 begin; 事务开始6.3 select * from test where 1=1 and id =1 for update;这样就把选到的记录⾏锁上了,再开⼀个SQLyog,也执⾏以上相同的操作,就会⼀直wait在那⾥.6.4 commit; 提交6.5 rollback; 回滚6.6 set autocommit=0;后应该加上set transaction isolation level read committed;这样其它客户端就能看到commit的数据,疑问:如果不设置set transaction isolation level read committed;如果两个客户端都select 相同的数据,⼀个客户端修改然后提交,另⼀个客户端不提交当前事务的前提下,去执⾏select ,取不到另⼀客户端提交的数据,不知道SQLyog默认的事务级别是什么样的.7. SQLyog中查看mysql的状态,show global variables like '%lock%'; 是个好⽅法.对于事务锁(例如for update)报Lock wait timeoutexceeded ,只能通过修改my.ini⽂件innodb_lock_wait_timeout = 100;才能⽣效.8. linux下修改⽤户密码 mysqladmin -u root password "new_pass"。
SpringBoot如何解决Mysql断连问题
SpringBoot如何解决Mysql断连问题在Spring Boot JPA连接Mysql的过程中,经过 8⼩时后会发现断连的情况。
application.properties配置如下(此坑我跳过,欢迎⼊坑):spring.datasource.url=jdbc:mysql://localhost/testername=dbuserspring.datasource.password=dbpassspring.datasource.driver-class-name=com.mysql.jdbc.Driver原因分析:mysql在默认的情况下,如果发现⼀个连接空闲时间超过8⼩时,将会在数据库端⾃动关闭这个连接。
(mysql wait_timeout 为8⼩时)。
解决⽅式:1 . Mysql 5 版本之前可以通过在URL后⾯加⼊autoReconnect=true,如:spring.datasource.url=jdbc:mysql://localhost/test?autoReconnect=true2 . application.properties⽂件中加⼊:spring.datasource.test-on-borrow=falsespring.datasource.test-while-idle=truespring.datasource.time-between-eviction-runs-millis= 36000003 . 粗暴点的直接修改 wait_timeout 时间:show global variables like 'wait_timeout';推荐第⼆种⽅式以上就是本⽂的全部内容,希望对⼤家的学习有所帮助,也希望⼤家多多⽀持。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
解决数据库连接池连接mysql 时,8小时mysql 自动断开连接的问题文章分类:数据库解决数据库连接池连接mysql 时,8小时mysql 自动断开所有连接的问题最近有个问题非常讨厌,我们的工程中使用自己的连接池连接mysql 数据库,可mysql 数据库8小时就会自动断开所有链接,连接池就失效,需要重新启动tomcat 才有效,呵呵,服务器可不能老是用“人工智能”来干预啊,后来翻了一下mysql 的手册,发现mysql 有解决办法,下面就是最简单的解决办法:连接数据库的时候加上autoReconnect=true 这个参数:
jdbc:mysql://localhost:3306/accounant?useUnicode=true& characterEncoding=UTF-8&au toReconnect=true 但是,在mysql 手册中有这样一段话:autoReconnect 驱动程序是否应尝试再次建立失效的和/或死连接?如果允许,对于在失效或死连接上发出的查询(属于当前事务),驱动程序将抛出异常,但在新事务的连接上发出下一个查询时,将尝试再连接。
不推荐使用该特性,这是因为,当应用程序不能恰当处理SQLExceptions 时,它会造成与会话状态和数据一致性有关的副作用,设计它的目的仅用于下述情况,即,当你无法配置应用程序来恰当处理因死连接和/或无效连接导致的SQLExceptions 时。
作为可选方式,可将MySQL 服务器变量“wait_timeout”设置为较高的值,而不
是默认的8 小时。
呵呵,不知道这种“副作用”会产生什么后果,难道会使tomcat 崩溃??会产生“数据一致性”问题??保险一点的办法还是增加“wait_timeout”这个值吧,把28800 设置成更大的值,这样应该就不会有什么问题了吧。
注:目前我使用的是autoReconnect 这种方式,未发现什么问题。