? 數(shù)據(jù)庫的報警可以拆分為很多類別，但是有一點是無論如何都跑不掉的纷妆，而且花樣百出，那就是磁盤空間報警晴弃。
? 在我的認知中掩幢，磁盤空間報警可以從上向下，從下向上的看待上鞠，如果從下向上看待际邻，磁盤空間類報警的處理方法相對比較簡單，只要分析了空間使用瓶頸旗国，合理處理是按部就班的事情枯怖，重復度較高，難度適中能曾，見效快度硝。而從上向下看待，磁盤空間類報警是我們必須要搞定的一場硬仗寿冕，因為系統(tǒng)類報警蕊程，CPU，內(nèi)存驼唱，磁盤藻茂，其中CPU,內(nèi)存類報警的原因都不太明朗，需要做更進一步的分析，而處理方法則需要結合業(yè)務的改造或者系統(tǒng)層面的調(diào)整優(yōu)化才能見效辨赐，磁盤類報警則相對來說屬于性價比較高的优俘，對于運維側的需求則需要更進一步，那就是在重復度掀序，復雜度的平衡中找到一種普適的處理辦法帆焕，能夠將這部分工作逐步的通過自動化方式處理，也就是從處理故障變?yōu)楣收献杂Ｊ健?
在節(jié)假日碰到磁盤報警是一種煎熬不恭，如果已經(jīng)在旅行途中叶雹，收到一條報警短信就像吃了蒼蠅一樣難受，大體有如下的一些處理方式：
一.系統(tǒng)層預處理：
在節(jié)假日前换吧，我們一般會做兩類工作：
第一類是做系統(tǒng)的全面巡檢折晦，主要涉及如下的幾個指標，我們會匯總為一個指標巡檢大盤：
1）磁盤空間使用率沾瓦，拆分為根目錄使用率和數(shù)據(jù)目錄使用率
2）內(nèi)存使用率
3）CPU使用率
4）inode使用率
5）系統(tǒng)負載情況
6）數(shù)據(jù)庫延遲
這份指標能夠發(fā)現(xiàn)絕大多數(shù)明顯的問題满着，基本掃清之后就能夠杜絕大部分的隱患。?
第二類工作暴拄，我們會把監(jiān)控報警的閾值降低漓滔，比如磁盤空間的閾值為80%~85%左右，一般會降為75%左右乖篷，這樣可以把一部分潛在的隱患也一并處理掉。?
如此一來能夠杜絕大部分硬傷的報警透且，當然這個工作的潛在問題就是人工干預較為明顯撕蔼，如果能夠做自動適配和指標回置，整個過程會更加有彈性秽誊。?
二.系統(tǒng)層處理
系統(tǒng)層處理的硬傷問題相對比較少鲸沮，主要碰到幾類：
1）查看系統(tǒng)層的空間使用異常，但是進程沒有釋放相關的句柄锅论，導致空間沒有徹底釋放讼溺。?
比如一個nohup任務生成的日志比較大，我們手工刪除了生成的日志文件最易，但是空間卻沒有釋放怒坯，一般來說，可以使用lsof來得到相關的句柄的明細藻懒，也可以看到磁盤空間占用較高的文件對應的進程剔猿，順著這條線分析，
常用的命令為：lsof|grep deleted 嬉荆，即可查找相關的進程
2）inode異常归敬，inode異常會導致很多奇怪的問題，比如數(shù)據(jù)分區(qū)無法寫入文件，數(shù)據(jù)庫無法登陸等汪茧，有一部分原因是crontab產(chǎn)生的大量碎片文件導致椅亚，可以通過如下的路徑：
/var/spool/postfix/maildrop
/var/spool/clientmqueue/
來進行快速的清理。
如果文件較多舱污，可以使用xargs分批刪除
# ls -l 2020*|wc -l
-bash: /bin/ls: Argument list too long
0
可以采用-n選項
ls | xargs -n 20 rm -f
如果數(shù)量達到一定程度依然會報錯什往，可以使用find+xargs的組合方式。?
如下效果較為穩(wěn)定，可以根據(jù)find的通配模式進行匹配清理奔脐。
find . -name "20200825*" | xargs rm -f '20200825*'
三.數(shù)據(jù)庫層處理
數(shù)據(jù)庫層的清理可做的空間相對比較大铜幽，前提是你給自己預留的空間要足夠大，否則坑足夠大處理起來會比較糾結省古。
1）binlog配置和清理
binlog的配置主要有參數(shù)expire_logs_days控制，如果出現(xiàn)空間問題丧失，而且我們確認了主從復制等基本配置豺妓，就可以調(diào)整expire_logs_days的配置，比如從7天調(diào)整為3天等布讹。
如果binlog在短時間內(nèi)產(chǎn)生的數(shù)量比較大琳拭，參數(shù)的控制已經(jīng)滿足不了了，則可以使用purge binary logs to 'xxx'的方式進行快速處理描验，當然處理的核心都是主從延遲情況白嘁。?
如果因為主從延遲較大，則可以專注于處理延遲的一些臨時配置膘流，比如雙1配置調(diào)整絮缅，并行復制線程等配置。
2）回收站
數(shù)據(jù)庫回收站模式在MySQL中是沒有的呼股，不代表我們不需要做耕魄，有很多敏感的數(shù)據(jù)清理任務造成的影響都具有延遲性，比如數(shù)據(jù)清理之后幾天之后業(yè)務側需要用的時候才會找過來彭谁，當然這個過程的敏感度可以更快一些吸奴，但是不能作為我們無法處理的借口。
數(shù)據(jù)庫的回收站在MySQL的基本原理就是移形換位缠局，把一張表通過renmae的方式快速的轉移到一個獨立的歸檔庫下面则奥，比如test_arch，在這個數(shù)據(jù)庫中的表可以按照時間順序進行數(shù)據(jù)清理甩鳄，這樣表中的數(shù)據(jù)就可以保存的時間就更長了逞度，我印象中處理最長的數(shù)據(jù)是一個月，整個恢復的工作都是秒級妙啃，著實讓業(yè)務同學目瞪口呆档泽。
?3）InnoDB表格式row_format修改為compressed
如果有些數(shù)據(jù)表存放的是日志數(shù)據(jù)俊戳，而且日志數(shù)據(jù)出現(xiàn)了爆發(fā)式增長，那么一種快速的適配方法就是使用compressed的數(shù)據(jù)格式馆匿，經(jīng)過測試抑胎，在有些場景下的壓縮率達到了近50%，而且查取效率依然很高渐北，對于存儲方面的收益更高阿逃，比如一個業(yè)務的數(shù)據(jù)保留需要控制在2個月，一種方式是擴容一倍的存儲空間赃蛛，一種是開啟compressed模式恃锉，在我們已驗證的業(yè)務場景中算是取得了初步的效果。?
你們還有什么方法可以避免磁盤空間類問題的窘狀呕臂，歡迎留言破托。
