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

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

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

[root@bbsmysql121 backup]#mysqld_safe –user=mysql

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

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

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

ü 虛擬化后臺管理系統(tǒng)

發(fā)現(xiàn)存儲被塞滿了，問題很嚴(yán)重。

ü ssh登錄宿主系統(tǒng)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

系統(tǒng)日志/var/log/messages發(fā)現(xiàn)大量的磁盤io錯誤。

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

釋放磁盤空間

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

df-h

再登其它服務(wù)器，分區(qū)/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的目錄（寫這個文章時，我已經(jīng)刪掉了，沒有留存記錄），這些文件，從目錄名稱上看，應(yīng)該是備份數(shù)據(jù)庫自動生成的。不管它，先刪除。

肯定有人在系統(tǒng)做了自動任務(wù)，用指令crontab –l 查看，果然有發(fā)現(xiàn)：

#!/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 {} \;
~

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

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

備份策略錯誤

有專門的備份系統(tǒng)，應(yīng)該把數(shù)據(jù)備份到該系統(tǒng)上，而不是本地備份。

手段錯誤

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

修復(fù)磁盤錯誤

緊急聯(lián)系機房，請技術(shù)人員把KVM over 連接到宿主機，萬一系統(tǒng)引導(dǎo)不了，可遠(yuǎn)程查看或者進入單用戶模式進行 fsck一類的修復(fù)操作。

Ssh連宿主機系統(tǒng)debian，確認(rèn)被塞滿的磁盤空間被釋放，然后執(zhí)行reboot重啟系統(tǒng)。幾分鐘以后，系統(tǒng)正常引導(dǎo)。

后續(xù)操作

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

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

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

以上所述是小編給大家介紹的干掉一堆mysql數(shù)據(jù)庫，僅需這樣一個shell腳本詳解整合，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！