MySQL中wait_timeout的坑

OuZeBo發表於2019-03-28
MySqlAI

今天遇到了一個問題，一個專案，放到伺服器（tomcat）下面的跑，但第二天，總是報錯，專案還不能跑

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1 milliseconds ago.  The last packet sent successfully to the server was 1 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1127)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3715)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3604)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4155)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2615)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2838)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2082)
    at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1307)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2931)
    at com.alibaba.druid.filter.FilterEventAdapter.preparedStatement_execute(FilterEventAdapter.java:440)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2929)
    at com.alibaba.druid.proxy.jdbc.PreparedStatementProxyImpl.execute(PreparedStatementProxyImpl.java:131)
    at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:493)
    at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:59)
    at org.apache.ibatis.executor.statement.RoutingStatementHandler.query(RoutingStatementHandler.java:73)
    at org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:60)
    at org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:267)
    at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:137)
    at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:96)
    at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:77)
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:108)
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:102)
    at org.activiti.engine.impl.db.DbSqlSession.selectListWithRawParameter(DbSqlSession.java:443)
    at org.activiti.engine.impl.db.DbSqlSession.selectList(DbSqlSession.java:434)
.......

發現這個問題是MySQL的坑：

　　wait_timeout的作用是，設定非互動連線（就是指那些連線池方式、非客戶端方式連線的）的超時時間，預設是28800，就是8小時，超過這個時間，mysql伺服器會主動切斷那些已經連線的，但是狀態是sleep的連線。而我們後端程式是執行在windows下的，所以安裝的myodbc，並使用ado方式連線的，也就是連線池方式，這種方式的壞處是，當伺服器端去連線mysql的時候，連線池裡的連線已經被mysql主動斷開，這時取回的連線就是null，再加上程式裡對此沒有做判斷的話，接下來的對資料庫的一系列的操作都會出現問題。

 

解決方案：

《1》增加 MySQL 的 wait_timeout 屬性的值 （不推薦）

　　修改mysql安裝目錄下的配置檔案 my.ini檔案，這兩個引數的預設值是8小時(60*60*8=28800)

wait_timeout=1814400 
interactive_timeout=1814400 

《2》減少連線池內連線的生存週期

　　減少連線池內連線的生存週期，使之小於上一項中所設定的wait_timeout 的值。修改 c3p0 的配置檔案，在 Spring 的配置檔案中設定：

<bean id="dataSource"  class="com.mchange.v2.c3p0.ComboPooledDataSource">      
    <property name="maxIdleTime"value="1800"/>  
    <!--other properties -->  
 </bean>

《3》定期使用連線池內的連線

　　定期使用連線池內的連線，使得它們不會因為閒置超時而被 MySQL 斷開。修改 c3p0 的配置檔案,在 Spring 的配置檔案中設定：

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">  
    <property name="preferredTestQuery" value="SELECT 1"/>  
    <property name="idleConnectionTestPeriod" value="18000"/>  
    <property name="testConnectionOnCheckout" value="true"/>  
</bean>

 

相關文章