這篇文章主要介紹了幹掉一堆mysql數據庫，僅需這樣一個shell腳本，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨着小編來一起學習學習吧
一大早就被電話吵醒了，雲某項目數據庫全掛了，啓動不了（睡得太死，沒聽到報警短信），嚇得不輕啊！
電話中說所有mysql數據庫主庫都啓動不了，但從庫正常，懷疑是主庫去連其它阿里雲的主庫了。這些數據庫，以前是從阿里雲遷移到idc機房的，因此他有這個判斷。
趕緊打開電腦，連***，登錄其中一個數據庫服務器，試着執行如下命令啓動mysql服務
[root@bbsmysql121 backup]#mysqld_safe –user=mysql &
啓動失敗，又換一臺數據庫服務器嘗試，還是失敗。考慮到所有的數據庫都不能啓動，因此可以初步判定，可能是數據庫宿主機的問題導致的。
數據庫的底層設計是兩臺物理節點虛擬化，外加一臺物理機做備份。其中一臺物理機的虛擬機全部做mysql主庫，另一臺物理機的虛擬機做mysql從庫。
先放棄在虛擬機進行故障排查，趕緊登錄宿主機系統。接下來，從兩個方面排查問題所在。
ü 虛擬化後臺管理系統
發現存儲被塞滿了，問題很嚴重。
ü ssh登錄宿主系統debian
[6885005.756183] Buffer I/O error on dev dm-16, logical block 34667776, lost async page write
[6885005.757292] Buffer I/O error on dev dm-16, logical block 34667792, lost async page write
[6885005.758210] Buffer I/O error on dev dm-16, logical block 34667808, lost async page write
[6885005.759079] Buffer I/O error on dev dm-16, logical block 34667824, lost async page write
[6885005.759922] Buffer I/O error on dev dm-16, logical block 34667840, lost async page write
[6885005.760723] Buffer I/O error on dev dm-16, logical block 34667856, lost async page write
系統日誌/var/log/messages發現大量的磁盤io錯誤。
綜合上述發現，基本可以斷定是磁盤出了問題：一個問題是proxmox劃定的存儲空間被塞滿，另一個是磁盤io錯誤。知道問題所在以後，接下來的處理方案有兩個：修復錯誤或者把從庫提升爲主庫。考慮到待機問題，還是儘量爭取修復主庫吧，實在不能修復，再用第二套方案（提升從庫）。
釋放磁盤空間
爲什麼磁盤空間會塞滿呢？應該有人在虛擬機上幹了啥，而且可能是每個虛擬機都進行相同的操作，纔會導致宿主機磁盤空間迅速填滿。隨便登錄某個運行mysql數據庫的虛擬機，執行命令
df-h
再登其它服務器，分區/dev/sdb1也是使用了90%以上。進入目錄/data，運行如下指令查看目錄空間佔用情況：
[root@cumysql121 data]# du -hs *
4.0K backup
59G db_pkg
59G mysql_db
[root@cumysql121 data]# cd backup
[root@cumysql121 backup]# du -hs *
好傢伙，好幾個50多G的目錄（寫這個文章時，我已經刪掉了，沒有留存記錄），這些文件，從目錄名稱上看，應該是備份數據庫自動生成的。不管它，先刪除。
肯定有人在系統做了自動任務，用指令crontab –l 查看，果然有發現：
#!/bin/bash
/usr/local/xtrabackup/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --passwor='+N4dohask+MsLhG' /data/backup/
find /data/backup/* -mtime +1 -exec rm -fr {} \;
~
初一看這個腳本沒什麼問題，再仔細看，最後一行是符號“~”,有問題啊！寫腳本的人的意圖是每天進行一次備份數據庫備份，然後刪除前一天的歷史備份數據，這樣就不會把磁盤塞滿了。
但是這有兩個致命的問題，這裏分別描述之。
備份策略錯誤
有專門的備份系統，應該把數據備份到該系統上，而不是本地備份。
手段錯誤
備份腳本寫好以後，應該手動執行，以驗證其正確性。而不是寫完，直接扔在上邊不管。
修復磁盤錯誤
緊急聯繫機房，請技術人員把KVM over 連接到宿主機，萬一系統引導不了，可遠程查看或者進入單用戶模式進行 fsck一類的修復操作。
Ssh連宿主機系統debian，確認被塞滿的磁盤空間被釋放，然後執行reboot重啓系統。幾分鐘以後，系統正常引導。
後續操作
查看系統日誌，沒有磁盤io報錯，創建目錄及文件，正常；啓動各虛擬機、啓動其上的數據庫，都正常了。
通知各路人馬，從業務層面檢查是否正常。片刻，短信來一堆恢復信息，心裏踏實多了。不用說，是項目方的sa乾的這個好事，並且沒有通知任何人。
私下給他說，這事自己跟其它人解釋，以後幹有風險的事情，最好相互通知一下。
以上所述是小編給大家介紹的幹掉一堆mysql數據庫，僅需這樣一個shell腳本詳解整合，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對神馬文庫網站的支持！