昨晚收到一則求助，一個用戶的本地數據庫的重要數據由於誤操作被刪除，需要進行緊急恢復，用戶的數據庫日常並沒有進行過任何備份，binlog也沒有開啟，所以從備份和binlog入手已經成為不可能，咨詢了丁奇，發了一篇percona的文章給我，頓時感覺有希望，於是到percona的官網上下載了恢復工具：
一.安裝：
.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz .cd percona-data-recovery-tool-for-innodb-0/mysql-source/ ../configure .cd percona-data-recovery-tool-for-innodb-0 .make
二.解析ibd文件：
此過程會將表的idb文件解析為很多的page，innodb的page分為兩大部分，一部分一級索引部分（primary key），另一部分為二級索引部分（secondary key），所以解析出來的idb包括了主鍵數據和索引數據兩大部分（如果該表有多個二級索引，則會生成多個文件）
./page_parser -5 -f t_bibasic_storage.ibd
參數解釋：
-5：代表 row format為Compact
-f：代表要解析的文件
結果如下：
pages-1377707810/FIL_PAGE_INDEX
0-161 0-325 0-463 0-464 0-465
可以看到t_bibasic_storage.ibd解析出來5個文件（161為主鍵索引的index_id,325,463,464,465為二級索引的index_id,該id可以通過開啟innodb_table_monitor知曉）
三.生成表定義：
由於該工具在解析數據pages的時候，需要獲得該table的表結構定義，所以需要執行如下命令：
./create_defs.pl –host xxxx –port 3306 –user root –password xxx –db didb –table t_bibasic_storage >include/table_defs.h
上面的命令會將t_bibasic_storage表的表結構定義傳入到table_defs.h中，在生成了表結構定義后，重新make該恢復工具：
.make
四.開始恢復pages中刪除的數據：
在重新編譯工具后，執行如下命令：
./constraints_parser -5 -D -f pages-1377707810/FIL_PAGE_INDEX/0-161 >/tmp/t_bibasic_salessend.sql
參數：
-5 -f的參數和page_parser相同；
-D:該參數的含義為代表恢復刪除的數據頁；
恢復完成后生成如下語句和文件：
LOAD DATA INFILE ‘/tmp/t_bibasic_proinfo.dmp’ REPLACE INTO TABLE `t_bibasic_proinfo` FIELDS TERMINATED BY ‘\t’ OPTIONALLY ENCLOSED BY ‘”‘ LINES STARTING BY ‘t_bibasic_proinfo\t’ (id, procode, skuoid, skucode, skuname, catatt, dutydepoid, dutydepname, seasonatt, brandatt, prostatus, choosedate, syear, smonth, sday, created, unioncomcode);
/tmp/t_bibasic_salessend.sql 該文件就是我們需要load data的文本文件。
總結：
1）。該恢復工具只支持innodb存儲引擎，文件的格式需要為：Compact
2）。數據被誤刪除后，需要盡快將保護現場，停止數據庫，把idb文件拷貝出來，防止ibd文件寫入數據被覆蓋（筆者恢復的一個表中，由於數據刪除后，表中仍有大量寫入，導致大部分數據沒有恢復出來）；
3）。千叮囑萬囑咐，數據庫的備份重於泰山；
更多信息見：
BTW：
按照上面的方法進行還原，只還原出部分數據，不知道原因，環境和刷寫機制相關，待確認！