看到這個 故障分析 | 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的配置可以自己把控，虛擬記憶體究竟多大，專業的事交給專業的人，也是一個專業問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/50677.html
標籤：MySQL
下一篇：mysql存盤中文亂碼