一大早就被電話吵醒了，云某項(xiàng)目數(shù)據(jù)庫(kù)全掛了，啟動(dòng)不了（睡得太死，沒(méi)聽(tīng)到報(bào)警短信），嚇得不輕??！

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

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

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

啟動(dòng)失敗，又換一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器嘗試，還是失敗?？紤]到所有的數(shù)據(jù)庫(kù)都不能啟動(dòng)，因此可以初步判定，可能是數(shù)據(jù)庫(kù)宿主機(jī)的問(wèn)題導(dǎo)致的。

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

先放棄在虛擬機(jī)進(jìn)行故障排查，趕緊登錄宿主機(jī)系統(tǒng)。接下來(lái)，從兩個(gè)方面排查問(wèn)題所在。

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

發(fā)現(xiàn)存儲(chǔ)被塞滿(mǎn)了，問(wèn)題很?chē)?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)大量的磁盤(pán)io錯(cuò)誤。

綜合上述發(fā)現(xiàn)，基本可以斷定是磁盤(pán)出了問(wèn)題：一個(gè)問(wèn)題是proxmox劃定的存儲(chǔ)空間被塞滿(mǎn)，另一個(gè)是磁盤(pán)io錯(cuò)誤。知道問(wèn)題所在以后，接下來(lái)的處理方案有兩個(gè)：修復(fù)錯(cuò)誤或者把從庫(kù)提升為主庫(kù)?？紤]到待機(jī)問(wèn)題，還是盡量爭(zhēng)取修復(fù)主庫(kù)吧，實(shí)在不能修復(fù)，再用第二套方案（提升從庫(kù)）。

釋放磁盤(pán)空間

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

df-h

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

[root@cumysql121 data]# du -hs *
4.0K backup
59G db_pkg
59G mysql_db
[root@cumysql121 data]# cd backup
[root@cumysql121 backup]# du -hs *

好家伙，好幾個(gè)50多G的目錄（寫(xiě)這個(gè)文章時(shí)，我已經(jīng)刪掉了，沒(méi)有留存記錄），這些文件，從目錄名稱(chēng)上看，應(yīng)該是備份數(shù)據(jù)庫(kù)自動(dòng)生成的。不管它，先刪除。

肯定有人在系統(tǒng)做了自動(dò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 {} \;
~

初一看這個(gè)腳本沒(méi)什么問(wèn)題，再仔細(xì)看，最后一行是符號(hào)“~”,有問(wèn)題??！寫(xiě)腳本的人的意圖是每天進(jìn)行一次備份數(shù)據(jù)庫(kù)備份，然后刪除前一天的歷史備份數(shù)據(jù)，這樣就不會(huì)把磁盤(pán)塞滿(mǎn)了。

但是這有兩個(gè)致命的問(wèn)題，這里分別描述之。

備份策略錯(cuò)誤

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

手段錯(cuò)誤

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

修復(fù)磁盤(pán)錯(cuò)誤

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

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

后續(xù)操作

查看系統(tǒng)日志，沒(méi)有磁盤(pán)io報(bào)錯(cuò)，創(chuàng)建目錄及文件，正常；啟動(dòng)各虛擬機(jī)、啟動(dòng)其上的數(shù)據(jù)庫(kù)，都正常了。

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

私下給他說(shuō)，這事自己跟其它人解釋?zhuān)院蟾捎酗L(fēng)險(xiǎn)的事情，最好相互通知一下。

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

最新評(píng)論