【MySQL】Too many connections 案例一則

一  前言
   DBA 運維就是填坑的過程，其他人挖坑，自己填；自己挖坑，自己填，說多了都是淚。好吧言歸正傳，今天凌晨忙碌了一個通宵做IDC 互動機維護改造以及升級資料庫伺服器的事情，需要重啟伺服器。重啟完成OS和重新部署資料庫周邊配套設施之後，系統沒有問題，早上8點多開始資料庫的error log 一直出現，別問為啥現在才處理(我補覺到11點多 ，13點才到公司。)
二 排查
  上面的報警資訊雖然不嚴重，但是error log一直有warnning資訊寫入，總是要解決的。遇到“Too many connections”報錯通常的情況是當前的資料庫連線數超過了系統 max_connections，max_user_connections 設定的大小。從這方面入手，具體的排查思路。通常會檢查
  1 資料庫能否登陸，登陸是否會報錯，但是登陸db 無異常。
  2 檢查 max_connections，max_user_connections的大小配置
  
  3 檢查資料庫系統的連線分佈，如下圖 顯然都正常的 ，系統配置 4000個連線，單個使用者300多個連線 ，遠遠小於系統設定的值。

     分析到這裡似乎陷入了僵局。在當前連線數 < max_connections 且當前連線數< max_user_connections 的時候，竟然出現了 "[Warning] Too many connections ",於是乎問了其他DBA同行，擴充一下思路，他們也表示差異，也無其他思路。
     和凌晨一起做變更的同事反饋目前遇到的問題，他的提示一語驚醒夢中人---我們啟用sql-killer(類似pt-killer實時監測系統，有執行時間超過1.02s左右的sql 就會kill掉)是透過管理埠連線資料庫。
     什麼是管理埠---在MySQL啟動時使用該引數extra_port指定一個埠號(不要和正常的資料庫服務埠衝突)，Percona Server會監聽來自該埠的請求。啟用該引數可以解決使用thread_pool特性時，由於所有的連線池worker忙於處理慢querey或者被鎖定導致DBA無法透過正常的埠連線DB, 以便DBA可以正常維護資料庫。顯然使用管理埠的初衷是好的 ，也是避免慢查詢堵住資料庫，sql-killer可以從管理埠連線到db，然後kill 產生慢查詢的會話。
    於是我們把sql-killer 停止，果然 error資訊也隨之停止。從管理埠方面檢查發現 extra_max_connections 重啟之後 變為1 ，導致sql-killer請求無法連線，報"Too many connections " 。知道原因之後 就是動態修改例項中的引數，修改配置檔案中的引數，然後重啟sql-killer ，至此問題解決。
三 小結
     解決這個異常大概花費了大約1.5h，究其原因還是對自己的系統掌握不夠，資料庫配置檔案方面沒有進行標準化，導致一系列的後續問題，假如沒有同事提醒還有工具透過管理埠進行資料庫連線，估計我需要花費更久的時間來排查問題。以後自己要梳理資料庫標準化的配置，統一到所有資料庫。
     常規的思維解決常規的問題。