记一次MySQL删库的数据恢复

昨天因为不可描述的原因，数据库直接被 drop database 删除。在***时间停止数据库服务和 Web 服务，备份 MySQL 数据目录下的所有文件之后，开始走上数据恢复之路。

成都创新互联公司专注于康保网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供康保营销型网站建设，康保网站制作、康保网页设计、康保网站官网定制、小程序定制开发服务，打造康保网络公司原创品牌,更为您提供康保网站排名全网营销落地服务。

***次干这种事，各种不得法。因为我们既没有备份，也没有开启 binlog，连 innodb_file_per_tabe_也没有。一番折腾后向***的朋友圈求救，朋友给了两个链接，最终救了一下命。以下先按编号记下 URL，后续引用之。

1、http://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database

2、https://github.com/chhabhaiya/undrop-for-innodb

3、https://twindb.com/how-to-recover-innodb-dictionary/

其中 URL1 和 URL3 的内容基本上相同，是整个恢复工作的蓝本。URL2 是 URL1 中引用的一个 twindb 团队开发的一个工具，现在他们官方已经删除了，URL2 是该工具的一个 fork，或者说是备份。

恢复过程以 URL3 为蓝本，先去 URL2 git clone 一份代码下来，然后按其说明编译，我们在 ubuntu server 14.04 64bit 版本的情况下，成功编译完成，编译中需要安装各种依赖不表。

然后用 stream_parser 处理 ibdata1 文件，接下来恢复 SYS_TABLES 和 SYS_INDEXES，建议此过程中严格遵守参考资料，比如把这些资料恢复到 dumps/default 目录中，而不是随意起名，以免横生枝节。

这里还有一个坑，就是 URL3 里用的 c_parser -4f 是会出错的，而 URL1 里用的是 c_parser -4Df ，就不会出错，所以大家做的时候一定要把这个 D 加上。感叹一下，如果不细心的人真的没法做这事！摔！

接下来按 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 目录，不然就再多一轮替换。

接下来的内容，大部分是参考文献里没有的了。

恢复数据字典后，就可以用 URL3 介绍的方式找出你对应的所有数据库和表的索引 ID 了。这个时候就遇到为 c_parser 提供数据表建表语句的问题了，这个问题难就难在先有鸡还是先有蛋，一般来说，数据库都被删掉了，哪还有办法去搞出 CREATE TABLE 这种建表语句呢？好就好在我们用的是 django，它对数据迁移的***支持救了我一命。在这里讲一句题外话，使用类似 django/ror/laravel 等有数据迁移框架在此就看出多么重要了。只要在根据原有项目做一次 migrate，数据表就建好了，这时候只要用 mysqldump 导出对应表的建表语句即可：

 
 
 
 

  
  
  
  
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 的内容就会在导入数据的环节出错，暂时没有找到办法恢复这个数据。

以上就是整个恢复过程，枯燥、压力山大，这种事情我不想再经历了。如果你也遇到这样的数据恢复需求，希望这篇笔记能够帮到你。但也不要指望我能帮到你更多了，我的经验也仅止于此，天大地大，就此别过，不要找我。谢谢！

网站题目：记一次MySQL删库的数据恢复
分享路径：http://www.shufengxianlan.com/qtweb/news27/75227.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联