MySQL數(shù)據(jù)庫(kù)經(jīng)典錯(cuò)誤 十一 MySQL 數(shù)據(jù)庫(kù)連接超時(shí)的報(bào)錯(cuò)
2018-11-08 20:26:00
22825
MySQL 數(shù)據(jù)庫(kù)連接超時(shí)的報(bào)錯(cuò)
org.hibernate.util.JDBCExceptionReporter – SQL Error:0, SQLState: 08S01
org.hibernate.util.JDBCExceptionReporter – The last packet successfully received from the server was43200 milliseconds ago.The last packet sent successfully to the server was 43200 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 ‘a(chǎn)utoReconnect=true’ to avoid this problem.
org.hibernate.event.def.AbstractFlushingEventListener – Could not synchronize database state with session
org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been called. Invalid operation in this state.
org.hibernate.util.JDBCExceptionReporter – SQL Error:0, SQLState: 08003
org.hibernate.util.JDBCExceptionReporter – No operations allowed after connection closed. Connection was implicitly closed due to underlying exception/error:
** BEGIN NESTED EXCEPTION **
大多數(shù)做 DBA 的同學(xué),可能都會(huì)被開發(fā)人員告知,你們的數(shù)據(jù)庫(kù)報(bào)了這個(gè)錯(cuò)誤了,趕緊看看是哪里的問題。
這個(gè)問題是由兩個(gè)參數(shù)影響的,wait_timeout 和 interactive_timeout。
數(shù)據(jù)默認(rèn)的配置時(shí)間是 28800(8小時(shí))意味著,超過這個(gè)時(shí)間之后,MySQL 數(shù)據(jù)庫(kù)為了節(jié)省資源,就會(huì)在數(shù)據(jù)庫(kù)端斷開這個(gè)連接,MySQL 服務(wù)器端將其斷開了,但是我們的程序再次使用這個(gè)連接時(shí)沒有做任何判斷,所以就掛了。
解決思路:先要了解這兩個(gè)參數(shù)的特性,這兩個(gè)參數(shù)必須同時(shí)設(shè)置,而且必須要保證值一致才可以。
我們可以適當(dāng)加大這個(gè)值,8 小時(shí)太長(zhǎng)了,不適用于生產(chǎn)環(huán)境。因?yàn)橐粋€(gè)連接長(zhǎng)時(shí)間不工作,還占用我們的連接數(shù),會(huì)消耗我們的系統(tǒng)資源。
解決方法:可以適當(dāng)在程序中做判斷,強(qiáng)烈建議在操作結(jié)束時(shí)更改應(yīng)用程序邏輯以正確關(guān)閉連接,然后設(shè)置一個(gè)比較合理的 timeout 的值(根據(jù)業(yè)務(wù)情況來判斷)。