昨天由於不可描述的緣由,數據庫直接被 drop database
刪除。在第一時間中止數據庫服務和Web服務,備份MySQL數據目錄下的全部文件以後,開始走上數據恢復之路。mysql
第一次幹這種事,各類不得法。由於咱們既沒有備份,也沒有開啓binlog,連innodb_file_per_tabe_也沒有。一番折騰後向萬能的朋友圈求救,朋友給了兩個連接,最終救了一下命。如下先按編號記下 URL,後續引用之。laravel
其中URL1和URL3的內容基本上相同,是整個恢復工做的藍本。URL2是URL1中引用的一個twindb團隊開發的一個工具,如今他們官方已經刪除了,URL2是該工具的一個fork,或者說是備份。git
恢復過程以URL3爲藍本,先去URL2 git clone一份代碼下來,而後按其說明編譯,咱們在ubuntu server 14.04 64bit 版本的狀況下,成功編譯完成,編譯中須要安裝各類依賴不表。github
而後用 stream_parser
處理ibdata1
文件,接下來恢復SYS_TABLES
和 SYS_INDEXES
,建議此過程當中嚴格遵照參考資料,好比把這些資料恢復到dumps/default
目錄中,而不是隨意起名,以避免橫生枝節。sql
這裏還有一個坑,就是URL3裏用的c_parser -4f
是會出錯的,而URL1裏用的是c_parser -4Df
,就不會出錯,因此你們作的時候必定要把這個D加上。感嘆一下,若是不細心的人真的無法作這事!摔!shell
接下來按URL3的說明把數據字典導入 MySQL。這一步能夠不作,按URL1裏高票答案的方法來獲取索引ID,比較麻煩。URL3的方法應該會出這樣的錯:數據庫
ERROR 1148 (42000) at line 2: The used command is not allowed with this MySQL version
這是由於MySQL默認不啓用LOAD DATA LOCAL INFILE
致使的,須要給mysql
命令加上--local-infile
參數。這是參考文獻的一個坑。趟過這個坑之後,我能夠告訴你一個捷徑,就是URL2裏的代碼裏其實有一個文件recover_dictionary.sh
,它乾的就是恢復數據字典的事情,因此你只要把這個shell腳本里的mysql
都替換成mysql --local-infile -uroot -pxxxxx
就行,其中xxxx是指你的root帳號密碼,不過前提是你很聽話的用了前面說的dumps/default
目錄,否則就再多一輪替換。django
接下來的內容,大部分是參考文獻裏沒有的了。ubuntu
恢復數據字典後,就能夠用URL3介紹的方式找出你對應的全部數據庫和表的索引ID了。這個時候就遇到爲 c_parser
提供數據表建表語句的問題了,這個問題難就難在先有雞仍是先有蛋,通常來講,數據庫都被刪掉了,哪還有辦法去搞出CREATE TABLE
這種建表語句呢?好就好在咱們用的是django
,它對數據遷移的完美支持救了我一命。在這裏講一句題外話,使用相似django/ror/laravel等有數據遷移框架在此就看出多麼重要了。只要在根據原有項目作一次migrate,數據表就建好了,這時候只要用mysqldump
導出對應表的建表語句便可:markdown
mysqldump --add-drop-table=0 --add-lock=0 -d DBNAME TABLENAME -uroot -p > xxxx.sql
由於c_parser
很是弱,只處理CREATE TABLE
語句,多一點干擾都不行,因此上面的參數都是必要的。
接下來就是參考URL1把某一個表的數據恢復出來,這裏有一個坑,URL1裏說把數據恢復到dump.tsv裏,實際上是不對的,這裏應該用dumps/default/TABLENAME
,別問我爲何知道,我不會告訴你我找這個緣由找瞎了眼,好吧,跟你說,由於生成的load_cmd.sql
裏直接引用 dumps/default/TABLENAME
,沒法設置。因此最後咱們這裏可用的命令是:
./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000002410.page -t xxxx.sql > dumps/default/TABLENAME 2> load_cmd.sql
把數據恢復出來之後,執行
mysql --local-infile -uroot -p DBNAME < load_cmd.sql
就能夠把數據導進去了,記得在數據庫裏查詢一下有沒有成功,若是沒有數據恢復出來,應該是其中的某些環節出了問題。
這樣就成功恢復了某一個表,只要按這裏最後三條命令(導出建表語句、恢復數據、導入數據)重複地作下去,你就能把基本上全部的數據都恢復出來了。之因此說是「基本上」,緣由是我係統中使用了utf8mb4
編碼(爲了兼容emoji),結果是若是數據中有emoji的內容就會在導入數據的環節出錯,暫時沒有找到辦法恢復這個數據。
以上就是整個恢復過程,枯燥、壓力山大,這種事情我不想再經歷了。若是你也遇到這樣的數據恢復需求,但願這篇筆記可以幫到你。但也不要期望我能幫到你更多了,個人經驗也僅止於此,天大地大,就此別過,不要找我。謝謝!