程序異常處理不完善導致的mariadb掛起

2019-11-09 13:38:03

字體：大中小

來源：轉載

供稿：網友

今年上班第一天就遇到了生產事故~跟大家分享下處理流程。

故障表現：

1.數據庫連接數持續升高；2.show engine innodb status卡死；3.數據庫服務器cpu負載很低空閑98%-100%。內存正常；4.errorlog中沒有異常信息；5.應用全部hang住，無法打開正常頁面。

排查流程：

1.首先想到show engine innodb status，結果數據庫無法輸出。2.查看數據庫中的正在處理的transcation，發現數據庫中的長事務特別多(敏感起見數據庫，用戶屏蔽掉了)

有1300+的事務在running狀態，同時后續數據庫有新的請求進來

3.初步懷疑是數據庫中的長事務導致數據庫鎖異常，鎖請求沒有釋放導致后續的程序異常。zabbix中的鎖信息：

4.手工kill掉長事務進程，發現這個時候數據庫已經不能正常釋放連接數了，而新的請求還在不斷的加多。數據庫連接數已經漲到1600+。5.由于業務方壓力，只能強行重啟數據庫釋放資源后問題暫時解決。

問題復現：

暫時解決的問題肯定會復現的！果然在數據庫重啟后長事務又出現了。這次通過查詢數據庫中的長事務

發現數據庫中14:05的時候出現了異常鏈接，同時應用報鎖超時錯誤。通過查看事務等待可以發現801事務阻塞了后續的update請求

同時innodb的狀態信息可以看到該異常事務鎖住了20行記錄。

手工kill掉進程后，程序恢復正常。

后續解決方案：

1.生產環境中用到的是mariadb10.0.28，其中的xtradb有針對異常transcation kill的參數。通過設置SET GLOBAL innodb_kill_idle_transaction=60; 可以將空閑超過60秒的異常事務殺死來防止后續的鎖爭用和數據庫掛起的問題。2.同開發人員溝通，發現代碼中存有bug。在進行異常處理的時候沒有針對所有的exception進行rollback操作，而只是針對一種異常拋出錯誤并進行rollback。因此程序在其他異常的時候沒有及時告訴數據庫進行rollback或者commit結束該事務，而是程序直接異常退出造成數據庫鏈接處于running狀態。該狀態會一直持有請求的鎖、內存等資源，在并發量大的情況非常容易造成數據庫的掛起假死狀態。改代碼！3.在zabbix中監控locking信息，超過10000ms及時報警。

上一篇：MySQL 命令大全

下一篇：MySql（一）