Mycat佔用mysql串連數過多

標籤：mycat   mysql   串連數過多   timeout   

背景：mariadb，mycat中介軟體。
問題：DB串連數過多；開發使用程式使用串連池連mycat；
DB待最佳化項： interactive_timeout，wait_timeout 都是8小時預設值。
mycat配置：100個分區庫，和其他業務庫。現在分區庫用到16分區，後面尚未使用。
當前DB最大串連數：3000
mycat 版本：當前線上的mycat版本是1.5.8版本，推薦以後線上使用最穩定的 mycat1.6.5版本。

經DB和開發碰面瞭解 這兩個timeout時間不能縮短，所以常規的最佳化手段不能使用：
正常DB串連數1000，資料庫兩個timeout為300--500，參數可以全域動態生效。

公司線上DB前段時間建總出現串連數過多問題，正常來說串連數1000,已經能夠滿足大部分需求。
正常手段無法使用的時候，那麼就要找到DB為啥串連數過多。

1. 審計日誌
DB上部署過審計日誌，審計日誌部署請移步：審計日誌部署，審計日誌中可以查看到做壞事的壞小子是誰！
因為時間關係，未儲存。但是從審計日誌中發現大量訪問串連sql就是‘select 1‘ ，也是mycat串連mysql的串連。
且該連結連的是大量尚未使用的物理庫。
至此審計日誌只能判斷到這裡。
2. DB層面
mariadb物理庫 information_schema 中processlist表記錄串連相關資訊，比如 DB,HOST,INFO,STATUS等。而且能統計具體某個庫的串連數。
查詢後，發現很多沒有使用的DB中串連很多沒有釋放，大概佔總串連數的60%左右，使用指令碼 "kill id； "後串連仍舊重新串連。
這種情況很尷尬，找不到原因。
3. 審計日誌
再結合審計日誌，查看串連從哪來的，還是mycat 發過來的<heartbeat>select 1 </heartbeat>，暫時就可以定位mycat的heartbeat 問題，結合網上尋找的heartbeat演算法，
其中有一條是關於未用的DB串連演算法：如果當前DB一直有訪問，那麼連結該DB 的heartbeat暫不執行，未用的DB連結300秒重新串連該DB。

這演算法是個人的理解，因能力有限，代碼閱讀能力低，只能理解個大概；現也能判斷個大概方向。
4.更改mycat配置

• 當前mycat配置：<schema><table datanode ></table></schema>datanode
  

需要減少未使用的datanode，減少後發現，串連數並未減少。
kill id; 後還是串連數會重新增長。判斷單單更改datanode不是解決問題的辦法。

• 更改<datanode></datanode>:
  

刪除尚未使用的<datanode></datanode>，再次kill id; 操作。未用的<datanode></datanode>串連不再出現。

至此問題解決，實驗文字敘述較多，描述較少，僅供讀者參考。

Mycat佔用mysql串連數過多