一大早就被電話吵醒了，雲某專案資料庫全掛了，啟動不了（睡得太死，沒聽到報警簡訊），嚇得不輕啊！

電話中說所有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指令碼詳解整合，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對我們網站的支援！