看到這個 故障分析 | MySQL OOM 故障應如何下手，想起來幾天前也遇到一次MySQL服務因為OOM被殺掉的情況，記錄一下 背景：一個測試環境，由於Centos系統上沒有設置虛擬記憶體，運行的MySQL實例buffer_pool_size配置的有不合理，運行了一個較大的查詢 現象：前端工具執行某 ...
看到這個 故障分析 | MySQL OOM 故障應如何下手，想起來幾天前也遇到一次MySQL服務因為OOM被殺掉的情況，記錄一下
背景：
一個測試環境，由於Centos系統上沒有設置虛擬記憶體，運行的MySQL實例buffer_pool_size配置的有不合理，運行了一個較大的查詢
現象：
前端工具執行某個sql，一點擊執行，過幾秒鐘連接客戶端顯式斷開MySQL連接，第一次沒在意，以為是剛好遇到網路問題導致的。
因此又重新刷新連接，重新執行，然後又資料庫連接又斷開，於是又刷新連接，又執行又斷開……，奇怪的是每次反覆連接斷開連接斷開連接斷開……
完全相同的現象反覆幾次之後，才意識到哪裡好像的不對勁，難特麽道誰在玩我？
感覺是MySQL服務被重啟了，因為網路不可能總是在執行查詢的時候出現故障，於是查看MySQL啟動時間：
SELECT DATE_ADD(NOW(),INTERVAL -variable_value SECOND) AS startup_datetime FROM performance_schema.global_status WHERE variable_name = 'Uptime'
果不其然，從當時的時間點來看，剛剛啟動了不到一分鐘，看MySQL的errorlog，只是反覆記錄MySQL重啟恢復，Starting crash recovery...，Crash recovery finished.
MySQL自身的errorlog中是看不到什麼問題了，只能拉出來系統日誌，MySQL的服務進程竟然是OOM後被系統殺掉了，然後才回頭追溯各種配置，/var/log/message
後面其實還是有點疑惑，為什麼沒有吧這個OOM的信息記錄到MySQL自己的error log中呢？mysql自己的error log也只記錄了重啟恢復的過程。
可能是，連MySQL自己都被殺掉了，誰來記這個日誌呢。
不過好在是，mysqld進程被殺掉之後，一直在自動被喚醒，這下可以深刻地一直到mysql_safe進程的作用了，
教訓
包括資料庫和操作系統在內，一些基礎配置還是要做好的，MySQL的配置可以自己把控，虛擬記憶體究竟多大，專業的事交給專業的人，也是一個專業問題。
