錯誤場景介紹

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

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

查明原因

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

查驗

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

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

解決方法

1. 修改Mysql配置

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

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

可以通過修改my.ini文件永久改動超時時間,如下配置

interactive_timeout=28800000
wait_timeout=28800000

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

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

3. 增加自動重連選項

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

4. 定時執(zhí)行一個動作進行超時時間刷新

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

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

補充：連接總是被mysql回收_一般連接池是怎么處理mysql自動回收長時間

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

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

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

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

更準確的復(fù)制延時 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ù)制或降級的半同步復(fù)制下，誤差較大，無法準確的反映出整體復(fù)制延時。

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

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

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

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

更準確的復(fù)制延時 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ù)制或降級的半同步復(fù)制下，誤差較大，無法準確的反映出整體復(fù)制延時。

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

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

最新評論