昨天，由于莫名其妙的原因，数据库被dropdatabase直接删除了。在最后关头停止了数据库服务和web服务，并备份了MySQL数据目录下的所有文件后，开始走上数据恢复之路。第一次做这种事，各种无法无天。因为我们既没有开启备份也没有开启binlog，连innodb_file_per_tabe_都没有开启。几经折腾，求助于***的朋友圈，朋友给了我两个链接，总算是救了我一命。以下网址先按编号记录，后面会引用。1.http://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database2,https://github.com/chhabhaiya/undrop-for-innodb3，https://twindb.com/how-to-recover-innodb-dictionary/，其中URL1和URL3的内容基本相同，是整个恢复工作的蓝图。URL2是由URL1中引用的twindb团队开发的工具。现在他们已经正式删除了它。URL2是该工具的一个分支，或者说是一个备份。恢复过程是基于URL3，先到URL2gitclone一份代码，然后按照它的说明编译。我们在ubuntuserver14.0464bit版本的情况下编译成功，编译时需要安装各种依赖。然后使用stream_parser处理ibdata1文件，然后恢复SYS_TABLES和SYS_INDEXES。建议在这个过程中严格遵守参考资料，比如将这些资料还原到dumps/default目录下，不要随意命名，以免产生副作用。这里还有一个坑，就是URL3中使用的c_parser-4f会出错，而URL1中使用的c_parser-4Df不会出错，所以一定要在做的时候加上这个D。唉，一不小心，还真做不到啊！落下！接下来按照URL3中的说明将数据字典导入MySQL。这一步可以跳过。按照URL1中高票答案的方法获取索引ID比较麻烦。URL3的方法应该会产生这样的错误：ERROR1148(42000)atline2:TheusedcommandisnotallowedwiththisMySQLversion这是因为MySQL默认没有启用LOADDATALOCALINFILE，需要在mysql命令中加上--local-infile参数。这是一个引用的坑。走过这个坑，我可以告诉你一个捷径，就是在URL2中的代码中其实有一个文件recover_dictionary.sh，是用来恢复数据字典的，所以你只需要将这个shell中的mysql替换掉即可脚本用mysql--local-infile-uroot-pxxxxx就可以了，这里的xxxx指的是你的root账号密码，不过前提是你乖乖用上面说的dumps/default目录，不然又要进行一轮替换。以下大部分内容不在参考文献中。恢复数据字典后，可以使用URL3中介绍的方法，找出你对应的所有数据库和表的索引ID。这个时候遇到了提供数据表给c_parser建表语句的问题。这道题的难点在于先有鸡还是先有蛋。一般来说，数据库已经被删除了，所以没有办法想出CREATETABLE之类的建表语句呢？好在我们使用的是django，它对数据迁移的出色支持救了我一命。这里说个题外话，使用django/ror/laravel这样的数据迁移框架是多么的重要。只要按照原来的project做一个migrate，数据表就建好了。这时候只需要使用mysqldump导出对应表的建表语句：mysqldump--add-drop-table=0--add-lock=0-dDBNAMETABLENAME-uroot-p>xxxx.sql因为c_parser很弱，只处理CREATETABLE语句，多一点干扰是不够的，所以上面的参数是必须的。接下来就是引用URL1来恢复某张表的数据。这里有一个陷阱。URL1说恢复数据到dump.tsv，其实是错误的。你应该在这里使用dumps/default/TABLENAME。不要问我为什么知道，我不会告诉你我被这个原因蒙蔽了，好吧，我告诉你吧，因为生成的load_cmd.sql中直接引用了dumps/default/TABLENAME，不能设置.所以***这里我们可以使用的命令是：./c_parser-6fpages-ibdata1/FIL_PAGE_INDEX/0000000000002410.page-txxxx.sql>dumps/default/TABLENAME2>load_cmd.sql恢复数据后，执行mysql--local-infile-uroot-pDBNAME
