干掉一堆mysql數據庫，僅需這樣一個shell腳本

一大早就被電話吵醒了，云某項目數據庫全掛了，啟動不了（睡得太死，沒聽到報警短信），嚇得不輕啊！

電話中說所有MySql數據庫主庫都啟動不了，但從庫正常，懷疑是主庫去連其它阿里云的主庫了。這些數據庫，以前是從阿里云遷移到idc機房的，因此他有這個判斷。

趕緊打開電腦，連***，登錄其中一個數據庫服務器，試著執行如下命令啟動mysql服務

啟動失敗，又換一臺數據庫服務器嘗試，還是失敗。考慮到所有的數據庫都不能啟動，因此可以初步判定，可能是數據庫宿主機的問題導致的。

數據庫的底層設計是兩臺物理節點虛擬化，外加一臺物理機做備份。其中一臺物理機的虛擬機全部做mysql主庫，另一臺物理機的虛擬機做mysql從庫。

先放棄在虛擬機進行故障排查，趕緊登錄宿主機系統。接下來，從兩個方面排查問題所在。

ü 虛擬化后臺管理系統

發現存儲被塞滿了，問題很嚴重。

ü ssh登錄宿主系統debian

系統日志/var/log/messages發現大量的磁盤io錯誤。

綜合上述發現，基本可以斷定是磁盤出了問題：一個問題是proxmox劃定的存儲空間被塞滿，另一個是磁盤io錯誤。知道問題所在以后，接下來的處理方案有兩個：修復錯誤或者把從庫提升為主庫。考慮到待機問題，還是盡量爭取修復主庫吧，實在不能修復，再用第二套方案（提升從庫）。

釋放磁盤空間

為什么磁盤空間會塞滿呢？應該有人在虛擬機上干了啥，而且可能是每個虛擬機都進行相同的操作，才會導致宿主機磁盤空間迅速填滿。隨便登錄某個運行MySql數據庫的虛擬機，執行命令

再登其它服務器，分區/dev/sdb1也是使用了90%以上。進入目錄/data，運行如下指令查看目錄空間占用情況：

好家伙，好幾個50多G的目錄（寫這個文章時，我已經刪掉了，沒有留存記錄），這些文件，從目錄名稱上看，應該是備份數據庫自動生成的。不管它，先刪除。

肯定有人在系統做了自動任務，用指令crontab –l 查看，果然有發現：

初一看這個腳本沒什么問題，再仔細看，最后一行是符號“~”,有問題啊！寫腳本的人的意圖是每天進行一次備份數據庫備份，然后刪除前一天的歷史備份數據，這樣就不會把磁盤塞滿了。

但是這有兩個致命的問題，這里分別描述之。

備份策略錯誤

有專門的備份系統，應該把數據備份到該系統上，而不是本地備份。

手段錯誤

備份腳本寫好以后，應該手動執行，以驗證其正確性。而不是寫完，直接扔在上邊不管。

修復磁盤錯誤

緊急聯系機房，請技術人員把KVM over 連接到宿主機，萬一系統引導不了，可遠程查看或者進入單用戶模式進行 fsck一類的修復操作。

Ssh連宿主機系統debian，確認被塞滿的磁盤空間被釋放，然后執行reboot重啟系統。幾分鐘以后，系統正常引導。

后續操作

查看系統日志，沒有磁盤io報錯，創建目錄及文件，正常；啟動各虛擬機、啟動其上的數據庫，都正常了。

通知各路人馬，從業務層面檢查是否正常。片刻，短信來一堆恢復信息，心里踏實多了。不用說，是項目方的sa干的這個好事，并且沒有通知任何人。

私下給他說，這事自己跟其它人解釋，以后干有風險的事情，最好相互通知一下。

---------------------------

本文轉自sery博客51CTO博客

數據庫 Mysql Shell

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。