【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，究其原因還是對自己的系統掌握不夠，數據庫配置文件方面沒有進行標準化，導致一系列的后續問題，假如沒有同事提醒還有工具通過管理端口進行數據庫連接，估計我需要花費更久的時間來排查問題。以后自己要梳理數據庫標準化的配置，統一到所有數據庫。
     常規的思維解決常規的問題。