前言

最近利用MHA做好Mysql讀寫分離后，時不時有用戶反饋后臺發(fā)布文章時，報程序“通用異常"，經(jīng)問題排查，里面涉及應(yīng)用JDBC連接池參數(shù)及Mysql參數(shù)調(diào)整問題。

[[277851]]

問題回顧

異常日志描述：

從異常信息反映來看，問題關(guān)鍵有兩點

1. 數(shù)據(jù)庫連接池超時設(shè)置大于wait_timeout
2. 日志提示，可以通過驗證數(shù)據(jù)庫連接或者設(shè)置：autoReconnect=true 來避免此異常

從以上兩點可以推測

第一、應(yīng)用程序數(shù)據(jù)庫連接池超時參數(shù)設(shè)置有問題

第二、安裝Mysql數(shù)據(jù)庫時，對于Mysql的內(nèi)在參數(shù)wait_timeout沒有做實際場景的優(yōu)化處理

問題定位

wait_timeout參數(shù)具體用途

wait_timeout具體含義是服務(wù)器關(guān)閉非交互連接之前等待活動秒數(shù)。MySQL缺省配置情況下，wait_timeout的初始值是28800秒，也就是8小時。如果wait_timeout超時時間設(shè)置過大，在MySQL管理系統(tǒng)里會產(chǎn)生大量的SLEEP進程無法及時釋放，會導致服務(wù)器系統(tǒng)性能下降;同時該參數(shù)設(shè)置過小，會導致Mysql處理某些事務(wù)未處理，連接不可用狀態(tài)。

也就是說如果在wait_timeout設(shè)置期間內(nèi)，數(shù)據(jù)庫連接Connection一直處于空閑等待狀態(tài)，mysql內(nèi)部會自動關(guān)閉此連接，而應(yīng)用程序無法感知到，依然認為連接池合法持有該連接。當應(yīng)用端再次用該連接來進行數(shù)據(jù)庫操作時，就產(chǎn)生上述異常錯誤。

應(yīng)用端Druid數(shù)據(jù)庫連接池參數(shù)排查

發(fā)現(xiàn)連接池有個MaxWait參數(shù)設(shè)置過大：60000毫秒

druidDataSource.setMaxWait(60000) 

然后在CSDN上，發(fā)現(xiàn)有個同行碰到同樣的問題：

發(fā)現(xiàn)數(shù)據(jù)庫等待超時時間(wait_timeout)是28800s，也就是8小時，而應(yīng)用程連接池參數(shù)max-wait: 30000，所以導致項目判定該鏈接可用，而mysql判定該連接不可用導致連接失敗。

解決辦法

根據(jù)上面的分析思路，我們排查了Mysql生產(chǎn)庫，發(fā)現(xiàn)默認Mysql超時時間(wait_timeout)也是28800s，但是應(yīng)用層連接池MaxWait參數(shù)設(shè)置成60000，于是我把MaxWait參數(shù)設(shè)置成10000，小于Mysql超時時間(wait_timeout)：28800 ，在測試環(huán)境等待8小時后，報錯消失了。

其他擴展思路(來源網(wǎng)絡(luò))

思路一：在jdbc-url后添加 &autoReconnect=true，使用后無效，查的該方案只適用于Mysql4之前的版本有效

思路二：將mysql回收空閑連接的時間變長，mysql默認回收時間是8小時，可以在mysql目錄下的my.ini中增加下面配置，將時間改為1天。單位是秒，最大好像是24天。 此配置會拖累數(shù)據(jù)庫性能，隨棄用該方案。

思路三：配置druid鏈接池，使用 validation-query test-on-borrow: true test-while-idle: true 三種屬性，每次獲取數(shù)據(jù)庫連接時判斷該連接是否可用。同時設(shè)置druidDataSource.setPhyTimeoutMillis參數(shù)

連接最大存活時間，默認是-1(不限制物理連接時間)，從創(chuàng)建連接開始計算，如果超過該時間，則會被清理druidDataSource.setPhyTimeoutMillis(15000);

參考例子

目前項目中趨于穩(wěn)定的連接池參數(shù)優(yōu)化實戰(zhàn)，參考如下：

Druid連接池參數(shù)官方說明：