前幾天，加班到晚上10點多了，在回去的路上，朋友打來電話，說他們公司的開發維護人員在對線上系統進行版本更新時，不小心把線上的數據庫給drop掉了，叫我過去救火，唉！ 雖然在運維界也混跡多年，這情況也是頭一回見哈，懷着即興奮又擔心的心情去到現場，興奮是因爲可以好好的實戰一下，擔心是怕幫不到朋友，唉，廢話不多說，上“戰場”。
第一步，既然數據庫都被幹掉了，又沒做主從，只好把所有相關係統程序關閉。
第二步，查看一下每天一備的包，萬幸，凌晨3點半的時候，有做了一份全備，備份是方式是tar包整個目錄，binlog功能也有開着，今天的binlog日誌還在。馬上把tar包解壓出來，這裏省略一萬個字，才50GB的包，解壓花了將近1個小時的時間，只想說某寶的雲主機，硬盤讀寫真是一個坑。
第三步，校驗一下備份的看能不能用，爲了省時間，直接把解壓出來的庫文件夾，直接MV到mysql datadir 下，把mysql 啓起來，select 某個表的數據，提示表不存在，汗，難道備份的數據有問題，汗水都流出來了，show engines,查看引擎，再查看了一下my.ini，哈哈，原來用的是InnoDB引擎，不能直接單獨mv庫文件夾，不管了，直接把整個備份的文件夾直接MV過來，再校驗了一下數據，凌晨3點半之前的數據都完整無缺，這時候，心情纔開始美麗了一些，就算找不回DROP掉的數據，至少大部分的數據沒問題了，只少了今天凌晨3點半之後到晚上10點這大半天的數據。
第四步，找到今天的binlog日誌，對比了一下時間，找到那個mysql_bin.0000XX,直接cp到tmp目錄下，輸入該命令：mysqlbinlog --start-date="2016-01-20 03:30:00" --stop-date="2016-01-20 22:00:00" mysql_bin.0000xx > /tmp/test.sql，很快，sql語句就轉出來了，直接VIM看了一下最後一條sql語句，確認沒有drop database語句。
第五步，登錄mysql，直接source /tmp/test.sql；等了15分鐘吧，恢復完了，讓他們確認了下數據有沒有問題，最後確認沒問題，至此，凌晨2點半了，收工，回家……