MySQL讀寫分離后Druid連接池參數的優化方式

本篇內容主要講解“MySQL讀寫分離后Druid連接池參數的優化方式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL讀寫分離后Druid連接池參數的優化方式”吧!

問題回顧

異常日志描述：

從異常信息反映來看，問題關鍵有兩點

1. 數據庫連接池超時設置大于wait_timeout
   

2. 日志提示，可以通過驗證數據庫連接或者設置：autoReconnect=true 來避免此異常

從以上兩點可以推測

第一、應用程序數據庫連接池超時參數設置有問題

第二、安裝Mysql數據庫時，對于Mysql的內在參數wait_timeout沒有做實際場景的優化處理

問題定位

wait_timeout參數具體用途

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

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

應用端Druid數據庫連接池參數排查

發現連接池有個MaxWait參數設置過大：60000毫秒

druidDataSource.setMaxWait(60000)

然后在CSDN上，發現有個同行碰到同樣的問題：

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

解決辦法

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

其他擴展思路(來源網絡)

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

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

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

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

參考例子

目前項目中趨于穩定的連接池參數優化實戰，參考如下：

Druid連接池參數官方說明：

到此，相信大家對“MySQL讀寫分離后Druid連接池參數的優化方式”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！