快捷導(dǎo)航

vim引發(fā)的MySQL進(jìn)程掛掉的問題解決

更新時間：2025年09月24日 10:11:22 作者：漁不是魚

本文介紹了使用logrotate工具對MySQL日志進(jìn)行自動歸檔和管理,通過配置logrotate,可以實現(xiàn)按周歸檔,文件大于2G時執(zhí)行,保留最近兩周的數(shù)據(jù),感興趣的可以了解一下

背景

上周一個業(yè)務(wù)排查處理死鎖的時候的時候，先tail -n200 mysql-error.log，處理過
死鎖的小伙伴都知道，show engine innodb status\G只能看到最近一次的死鎖信息，
而對于歷史的死鎖信息需要開啟innodb_print_all_deadlocks_output這個參數(shù)，
一旦數(shù)據(jù)庫開啟了這個參數(shù)，就會將所有的歷史死鎖信息輸出到MySQL的error log。
而一條死鎖如果鎖定的行數(shù)或者記錄很多的話，一條死鎖記錄可能就會幾百行，
所以當(dāng)時一直看不到想要的信息，就直接vim打開查看了一下，結(jié)果直接就卡住了，
（后來恢復(fù)了,看了一下當(dāng)時的那個error log居然18GB）緊接著就收到報警信息，主庫MySQL進(jìn)程時間運行少于10min，然后就從庫也報警IO
線程停掉了。

解決排查過程

1.遇到報警第一瞬間上去修復(fù)主從復(fù)制，還好該庫不是一個核心業(yè)務(wù)而且是在業(yè)務(wù)低峰期，
qps非常低，所以主從自己重新連接上，恢復(fù)正常。
2.查看數(shù)據(jù)情況，數(shù)據(jù)
3接下來進(jìn)入問題排查過程，查看監(jiān)控，監(jiān)控如下：

可以看到監(jiān)控圖內(nèi)存使用率到一個點掉了下來，看起來是OOM導(dǎo)致的問題，
4.查看系統(tǒng)日志，查找元兇。

這里可以看到確實發(fā)生了OOM,但是可以看到是因為filebeat導(dǎo)致的，思考一下，肯定是因為
當(dāng)時vim的時已經(jīng)出發(fā)到邊界了，但是filebeat剛好在臨界值又去tail slow log剛好到達(dá)了OOM的觸發(fā)條件，引發(fā)了OOM
繼續(xù)往下看發(fā)現(xiàn)了問題：

可以看到這里kernel選擇殺死了分?jǐn)?shù)最高的mysqld進(jìn)程

PS: 這里說一下為什么,在OOM的時候，kernal殺掉了mysqld進(jìn)程，在OOM的情況下，系統(tǒng)會有一個打分策略，會kill掉分?jǐn)?shù)最高的進(jìn)程、

#關(guān)于OOM
linux OOM是由系統(tǒng)參數(shù)vm.overcommit_memory控制的.
#查看方式：
$ sysctl -a| grep vm.overcommit
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

#vm.overcommit_memory的取值
#簡單總結(jié)
0--用之前先申請，申請不到足夠空間拋出OOM（默認(rèn)值）
1--不申請直接使用，過載使用內(nèi)存，不觸發(fā)OOM
2--不允許過載使用內(nèi)存，不觸發(fā)OOM

#kernel score如何計算的，主要是通過下面值計算出來的
oom_score
oom_score_adj
#就是下面這兩個文件/proc/進(jìn)程號/下
$ ls -l /proc/197543/oom_score*
-r--r--r-- 1 mysql mysql 0 9月  15 18:40 /proc/197543/oom_score
-rw-r--r-- 1 mysql mysql 0 9月  15 18:40 /proc/197543/oom_score_adj

感興趣的可以繼續(xù)深入研究

所以可以看到我們在OOM并不是內(nèi)存使用率達(dá)到100%的時候才會拋出OOM異常，像我們監(jiān)控的時候95%就OOM了
5萬幸的是這次掛掉的是一個qps非常低的非核心業(yè)務(wù)庫，由于重啟速度也很快，在1s之內(nèi)完成，所以業(yè)務(wù)幾乎無任何影響

后續(xù)改進(jìn)措施

既然問題發(fā)生了，解決了，那么作為一個合格的DBA，接下來就應(yīng)該去考慮如何去做優(yōu)化，以及避免這種問題發(fā)生：
針對這次的問題，整理了以下的措施：

優(yōu)化告警策略，明明平常內(nèi)存使用已經(jīng)很高了，但是沒有報警提示
vim的時候注意，vim的時候一定要注意文件大小
定時歸檔日志文件，定時分割拆分清理錯誤日志，慢查詢?nèi)罩?/li>
合理分配數(shù)據(jù)庫使用buffer，如果這臺機(jī)器還有其他業(yè)務(wù)，比如canal，filebeat考慮調(diào)小buffer pool size大小
重要進(jìn)程保證不會被oom-killer kill掉，實現(xiàn)方式，可以把對應(yīng)進(jìn)程的oom_score_adj文件內(nèi)容調(diào)成一個比較小的負(fù)數(shù)，注意會有范圍的，在范圍之內(nèi)調(diào)小，然后使其在OOM的時候拿到一個比較低的分?jǐn)?shù)，避免被kill掉。

到此這篇關(guān)于vim引發(fā)的MySQL進(jìn)程掛掉的問題解決的文章就介紹到這了,更多相關(guān)MySQL進(jìn)程掛掉內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: