快捷導(dǎo)航

解決JDBC連接Mysql長時(shí)間無動(dòng)作連接失效的問題

更新時(shí)間：2021年03月24日 10:29:28 作者：看不見鯨魚的鼻子

這篇文章主要介紹了解決JDBC連接Mysql長時(shí)間無動(dòng)作連接失效的問題，具有很好的參考價(jià)值，希望對大家有所幫助。一起跟隨小編過來看看吧

錯(cuò)誤場景介紹

做的有一個(gè)項(xiàng)目使用JDBC手動(dòng)創(chuàng)建Connection實(shí)現(xiàn)了一個(gè)簡單的自定義數(shù)據(jù)庫連接池,用來支持Canal解析數(shù)據(jù)庫Binlog指定業(yè)務(wù)庫的插入修改SQL來進(jìn)行數(shù)據(jù)庫分表備份(按照月份)操作.

但是發(fā)現(xiàn)當(dāng)一個(gè)一段時(shí)間(較長)沒有進(jìn)行數(shù)據(jù)庫操作時(shí),連接都失效了,導(dǎo)致SQL執(zhí)行失敗失效提示為No operations allowed after connection closed

查明原因

經(jīng)過搜索發(fā)現(xiàn)這個(gè)問題是由于Mysql默認(rèn)一個(gè)已創(chuàng)建的長連接28800秒(八小時(shí))內(nèi)沒有任何動(dòng)作則會(huì)斷開連接,該值對應(yīng)參數(shù)為wait_timeout.當(dāng)超時(shí)時(shí)間內(nèi)有執(zhí)行動(dòng)作則會(huì)重新計(jì)時(shí)

查驗(yàn)

查詢Mysql超時(shí)連接時(shí)長命令show global variables like'wait_timeout'查看當(dāng)前設(shè)置的超時(shí)斷開連接時(shí)長.

將其改為10,本地服務(wù)運(yùn)行功能發(fā)現(xiàn)重現(xiàn)了No operations allowed after connection closed錯(cuò)誤,即確實(shí)是連接超時(shí)失效

解決方法

1. 修改Mysql配置

該方法不能根治這個(gè)問題,因?yàn)椴荒艽_認(rèn)服務(wù)空閑時(shí)長而精確設(shè)置timeout并且還會(huì)造成多余連接長時(shí)間未斷開而影響性能,所以不建議使用.建議在代碼層面進(jìn)行解決

通過set global wait_timeout=time(秒)來修改最長連接等待超時(shí)時(shí)間,但是這樣設(shè)置當(dāng)Mysql重啟失效

可以通過修改my.ini文件永久改動(dòng)超時(shí)時(shí)間,如下配置

interactive_timeout=28800000
wait_timeout=28800000

2. 連接丟棄重新創(chuàng)建連接

使用conn.isValid(int timeout)(秒)判斷是否失效返回true表示連接有效,返回false表示連接失效.當(dāng)失效時(shí)則重新獲取一個(gè)數(shù)據(jù)庫連接即可,之前的對象由于引用丟失會(huì)被回收掉.

3. 增加自動(dòng)重連選項(xiàng)

在URL最后添加autoReconnect=true參數(shù),jdbc:mysql://hostaddress:3306/xhb?autoReconnect=true.我這里對這個(gè)沒有效果,可能是對框架連接池有用.

4. 定時(shí)執(zhí)行一個(gè)動(dòng)作進(jìn)行超時(shí)時(shí)間刷新

比如默認(rèn)時(shí)間是八小時(shí),則每七小時(shí)對連接執(zhí)行一次select 1語句來刷新該連接在數(shù)據(jù)庫的超時(shí)等待時(shí)長

也可以1 2 4一起使用,來防止突然一個(gè)流量靜默期間后突發(fā)流量高峰而導(dǎo)致獲取連接不及時(shí)

補(bǔ)充：連接總是被mysql回收_一般連接池是怎么處理mysql自動(dòng)回收長時(shí)間

若干套 MySQL 環(huán)境，只有一套：

行為異常，e5a48de588b63231313335323631343130323136353331333436316239懷疑觸發(fā) bug

性能異常，比其他環(huán)境都要低

在這種場景下，我們一般的做法是首先控制變量，查看軟硬件配置，以及 MySQL 的參數(shù)配置。關(guān)于 MySQL 的參數(shù)配置對比，如果我們?nèi)斯Ρ鹊脑捴粫?huì)關(guān)注某些重點(diǎn)參數(shù)，而缺少了整體細(xì)節(jié)上的的對比。在這里我們推薦給大家 Percona Toolkit 中的一個(gè)工具 pt-config-diff

更準(zhǔn)確的復(fù)制延時(shí) pt-heartbeat在 MySQL 中，復(fù)制延遲可以理解為由兩部分組成：1. 主庫已經(jīng)生成了 BINLOG，但是還沒有發(fā)送給從庫 -- 我們在這里稱之為：日志延遲2. 從庫已經(jīng)接收到了 BINLOG，但是還沒有應(yīng)用完成 -- 我們在這里稱之為：應(yīng)用延遲MySQL 原生的查看復(fù)制延遲的手段為：show slave status\G中的Seconds_Behind_Master。這種觀測手法只能觀測出應(yīng)用延遲。在異步復(fù)制或降級(jí)的半同步復(fù)制下，誤差較大，無法準(zhǔn)確的反映出整體復(fù)制延時(shí)。

1. 在 Master 上循環(huán)插入：insert into database.heartbeat (master_now) values(NOW())

2. database.heartbeat 的變更會(huì)跟隨主從復(fù)制流向從庫

3. 系統(tǒng)當(dāng)前時(shí)間 - 從庫表中的時(shí)間 = 從庫實(shí)際的復(fù)制延時(shí)

更簡單的參數(shù)配置建議 pt-variable-advisortoolkit 中包含了一個(gè)簡單的 MySQL 參數(shù)優(yōu)化器，可以對參數(shù)配置做簡單的優(yōu)化建議。

更準(zhǔn)確的復(fù)制延時(shí) pt-heartbeat在 MySQL 中，復(fù)制延遲可以理解為由兩部分組成：1. 主庫已經(jīng)生成了 BINLOG，但是還沒有發(fā)送給從庫 -- 我們在這里稱之為：日志延遲2. 從庫已經(jīng)接收到了 BINLOG，但是還沒有應(yīng)用完成 -- 我們在這里稱之為：應(yīng)用延遲MySQL 原生的查看復(fù)制延遲的手段為：show slave status\G中的Seconds_Behind_Master。這種觀測手法只能觀測出應(yīng)用延遲。在異步復(fù)制或降級(jí)的半同步復(fù)制下，誤差較大，無法準(zhǔn)確的反映出整體復(fù)制延時(shí)。

更易用的調(diào)試工具 pt-pmp在某些情況下，我們肯定會(huì)遇到某些故障無法從日志，以及狀態(tài)命令中找到原因，需要深入到程序邏輯級(jí)別。又或者我們需要立即通過非常規(guī)手段恢復(fù)故障數(shù)據(jù)庫，但是又想保留足夠多的故障信息。來避免我們事后復(fù)現(xiàn)問題的頭疼。pt-pmp 便是在這種場景下幫助我們的工具。它會(huì)使用 gdb 來打印 mysqld 的堆棧信息，并把調(diào)用鏈相同的線程堆棧合并。堆棧合并的功能對于 MySQL 這種多線程的應(yīng)用非常有幫助，會(huì)節(jié)省我們大量的時(shí)間。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。

您可能感興趣的文章: