幹掉一堆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乾的這個好事，而且沒有通知任何人。

  

私下給他說，這事本身跟其它人解釋，之後幹有風險的事情，最好相互通知一下。