平臺XXXX系統無響應故障報告

 

1、故障時間：

              發生時間：2015.11.17  凌晨2:10點左右

              解決時間：2015.11.17  早上8:40分左右

2、故障解決人員：

               XXX

3、故障現象：

        XXX WEB、系統沒法登錄，經過堡壘機鏈接系統徹底無響應，數據庫主庫大量的查詢被阻塞，插入更新語句沒法執行

4、故障排查：

        首先經過堡壘機登錄XXX系統，查看狀態，可是因系統無響應，只有聯繫idc機房人員進行手動重啓系統。同時登錄平臺數據庫主庫系統查看MySQL進程狀態，顯示出大量的表須要等待XXX_order表的tableflush狀態完成（P-2所示）。大約10分鐘後XXX系統啓動完成，登錄後查看系統狀態，各個服務都運行良好。只是一直收到監控系統的報警：系統進程在不斷增長。應該能夠很清楚的知道是由於數據庫的XXX_order和XXX_task_queue表須要完成flushtable，而長時間沒有完成致使的。

5、故障解決：

         目前的主要問題就在如何解決阻塞的問題，當時經過查看系統進程大概有3000多個Waitingfor  table flush的SQL，所有是XXX庫（XXX_order）相關的表（P-2所示）。手工kill掉一些select類型的SQL並不能起做用，這時候應該找到產生阻塞的具體SQL纔對。以前對數據庫系統作了一個監控系統進程狀態的腳本，打開日誌文件，查看裏面具體的SQL（P-3所示）找到執行時間最長的那個，kill掉對應的SQL  ID應該就釋放了阻塞。大量的Waiting for  table flush 狀態消失，系統恢復正常。

P-1

P-2

 

P-3

6、故障緣由：

         因一個性能較差經過手工執行的SQL在經過堡壘機進行查詢時手工終止（ctrl+c）可是在MySQL實例已經開始了Copying數據到tmp表中，並無結束掉，仍是一直在數據庫中執行。查詢執行時間長達10多個個小時。同時備份的腳本啓動，開始出現阻塞的時間在凌晨2點鐘左右，那個時間正好是數據庫備份開始執行的時間，mysqldump會發出flushtables的動做，由於SQL執行的慢，致使沒法完成mysqldump須要對XXX_order和XXX_task_queue表的tableflush動做致使阻塞了其餘查詢，插入更新等對XXX_order和XXX_task_queue表的請求的堆積,同時XXX系統相關的計劃任務不少是每一分鐘執行一次，形成XXX的計劃任務不能及時執行完成，系統進程數量陡增（P-4所示），形成XXX系統崩潰。

P-4

         

7、問題解決方案

        1. 監控MySQL Processlist 的xxx_select帳號執行的時間，若是超過1800秒就將其線程進行kill掉終止執行。

        2. 經過Nagios監控MySQL Processlist中出現Waitingfor  table flush、Waitingfor table metadata lock和flushtable with read lock的數量，若是超過5個就要發出報警，運維人員介入處理，根據日誌來查找具體緣由

       3. 搭建一個新的專門處理查詢任務的從庫，此從庫不影響業務

8、故障後的反思：

                 經過此次故障應該吸收教訓：

        1. 對數據庫的任何操做都要謹慎、敬畏，由於數據是企業的生命。當進行增刪改查的時候就要知道形成的後果是什麼？操做前作好充分的測試，再去線上進行執行，好比看SQL的執行計劃是不是最優化的性能、是否會形成數據的不一致問題，主從是否會出現中斷等。不會對現有的業務形成影響，不然就不該該進行線上操做，切記！

        2. 運維在系統監控這邊執行的不是很到位，須要自我檢討。一般在手機接收到報警的時候第一時間進行處理（凌晨兩點左右），當時在看到手機報警的時候沒有看清是系統沒有響應了（熟睡中醒來看什麼都迷糊）手機登陸管理系統能ping的通XXX系統的網絡，結合報警類型來看只是暫時的無響應，但當收到大量報警時候，發現是比較嚴重的問題了，着手處理問題的時間在早上7點半左右，這期間有充足的時間去處理。而且監控系統在問題發生以前就已經預警了，並無引發重視！才形成後續更嚴重的問題！對於之後產生環境的報警應該加以重視，不能掉以輕心，將問題在萌芽狀態就要及時發現並處理！

       3. 對系統運行時狀態的即時轉存儲對於解決問題有很大的幫助，因此應該考慮對系統狀態作快照處理保存，以便查找問題出現的根本緣由。