? 數(shù)據(jù)庫的報警可以拆分為很多類別，但是有一點(diǎn)是無論如何都跑不掉的，而且花樣百出，那就是磁盤空間報警。

? 在我的認(rèn)知中，磁盤空間報警可以從上向下，從下向上的看待，如果從下向上看待，磁盤空間類報警的處理方法相對比較簡單，只要分析了空間使用瓶頸，合理處理是按部就班的事情，重復(fù)度較高，難度適中，見效快。而從上向下看待，磁盤空間類報警是我們必須要搞定的一場硬仗，因為系統(tǒng)類報警，CPU，內(nèi)存，磁盤，其中CPU,內(nèi)存類報警的原因都不太明朗，需要做更進(jìn)一步的分析，而處理方法則需要結(jié)合業(yè)務(wù)的改造或者系統(tǒng)層面的調(diào)整優(yōu)化才能見效，磁盤類報警則相對來說屬于性價比較高的，對于運(yùn)維側(cè)的需求則需要更進(jìn)一步，那就是在重復(fù)度，復(fù)雜度的平衡中找到一種普適的處理辦法，能夠?qū)⑦@部分工作逐步的通過自動化方式處理，也就是從處理故障變?yōu)楣收献杂Ｊ健?

在節(jié)假日碰到磁盤報警是一種煎熬，如果已經(jīng)在旅行途中，收到一條報警短信就像吃了蒼蠅一樣難受，大體有如下的一些處理方式：

一.系統(tǒng)層預(yù)處理：

在節(jié)假日前，我們一般會做兩類工作：

第一類是做系統(tǒng)的全面巡檢，主要涉及如下的幾個指標(biāo)，我們會匯總為一個指標(biāo)巡檢大盤：

1）磁盤空間使用率，拆分為根目錄使用率和數(shù)據(jù)目錄使用率

2）內(nèi)存使用率

3）CPU使用率

4）inode使用率

5）系統(tǒng)負(fù)載情況

6）數(shù)據(jù)庫延遲

這份指標(biāo)能夠發(fā)現(xiàn)絕大多數(shù)明顯的問題，基本掃清之后就能夠杜絕大部分的隱患。?

第二類工作，我們會把監(jiān)控報警的閾值降低，比如磁盤空間的閾值為80%~85%左右，一般會降為75%左右，這樣可以把一部分潛在的隱患也一并處理掉。?

如此一來能夠杜絕大部分硬傷的報警，當(dāng)然這個工作的潛在問題就是人工干預(yù)較為明顯，如果能夠做自動適配和指標(biāo)回置，整個過程會更加有彈性。?

二.系統(tǒng)層處理

系統(tǒng)層處理的硬傷問題相對比較少，主要碰到幾類：

1）查看系統(tǒng)層的空間使用異常，但是進(jìn)程沒有釋放相關(guān)的句柄，導(dǎo)致空間沒有徹底釋放。?

比如一個nohup任務(wù)生成的日志比較大，我們手工刪除了生成的日志文件，但是空間卻沒有釋放，一般來說，可以使用lsof來得到相關(guān)的句柄的明細(xì)，也可以看到磁盤空間占用較高的文件對應(yīng)的進(jìn)程，順著這條線分析，

常用的命令為：lsof|grep deleted ，即可查找相關(guān)的進(jìn)程

2）inode異常，inode異常會導(dǎo)致很多奇怪的問題，比如數(shù)據(jù)分區(qū)無法寫入文件，數(shù)據(jù)庫無法登陸等，有一部分原因是crontab產(chǎn)生的大量碎片文件導(dǎo)致，可以通過如下的路徑：

/var/spool/postfix/maildrop

/var/spool/clientmqueue/

來進(jìn)行快速的清理。

如果文件較多，可以使用xargs分批刪除

# ls -l 2020*|wc -l

-bash: /bin/ls: Argument list too long

0

可以采用-n選項

ls | xargs -n 20 rm -f

如果數(shù)量達(dá)到一定程度依然會報錯，可以使用find+xargs的組合方式。?

如下效果較為穩(wěn)定，可以根據(jù)find的通配模式進(jìn)行匹配清理。

find . -name "20200825*" | xargs rm -f '20200825*'

三.數(shù)據(jù)庫層處理

數(shù)據(jù)庫層的清理可做的空間相對比較大，前提是你給自己預(yù)留的空間要足夠大，否則坑足夠大處理起來會比較糾結(jié)。

1）binlog配置和清理

binlog的配置主要有參數(shù)expire_logs_days控制，如果出現(xiàn)空間問題，而且我們確認(rèn)了主從復(fù)制等基本配置，就可以調(diào)整expire_logs_days的配置，比如從7天調(diào)整為3天等。

如果binlog在短時間內(nèi)產(chǎn)生的數(shù)量比較大，參數(shù)的控制已經(jīng)滿足不了了，則可以使用purge binary logs to 'xxx'的方式進(jìn)行快速處理，當(dāng)然處理的核心都是主從延遲情況。?

如果因為主從延遲較大，則可以專注于處理延遲的一些臨時配置，比如雙1配置調(diào)整，并行復(fù)制線程等配置。

2）回收站

數(shù)據(jù)庫回收站模式在MySQL中是沒有的，不代表我們不需要做，有很多敏感的數(shù)據(jù)清理任務(wù)造成的影響都具有延遲性，比如數(shù)據(jù)清理之后幾天之后業(yè)務(wù)側(cè)需要用的時候才會找過來，當(dāng)然這個過程的敏感度可以更快一些，但是不能作為我們無法處理的借口。

數(shù)據(jù)庫的回收站在MySQL的基本原理就是移形換位，把一張表通過renmae的方式快速的轉(zhuǎn)移到一個獨(dú)立的歸檔庫下面，比如test_arch，在這個數(shù)據(jù)庫中的表可以按照時間順序進(jìn)行數(shù)據(jù)清理，這樣表中的數(shù)據(jù)就可以保存的時間就更長了，我印象中處理最長的數(shù)據(jù)是一個月，整個恢復(fù)的工作都是秒級，著實讓業(yè)務(wù)同學(xué)目瞪口呆。

?3）InnoDB表格式row_format修改為compressed

如果有些數(shù)據(jù)表存放的是日志數(shù)據(jù)，而且日志數(shù)據(jù)出現(xiàn)了爆發(fā)式增長，那么一種快速的適配方法就是使用compressed的數(shù)據(jù)格式，經(jīng)過測試，在有些場景下的壓縮率達(dá)到了近50%，而且查取效率依然很高，對于存儲方面的收益更高，比如一個業(yè)務(wù)的數(shù)據(jù)保留需要控制在2個月，一種方式是擴(kuò)容一倍的存儲空間，一種是開啟compressed模式，在我們已驗證的業(yè)務(wù)場景中算是取得了初步的效果。?

你們還有什么方法可以避免磁盤空間類問題的窘狀，歡迎留言。