關於使用MySQL binlog對資料進行恢複的實戰

關於使用MySQL binlog對資料進行恢複的實戰

前幾天，加班到晚上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點半了，收工，回家……

本文永久更新連結地址：