记一次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 的方法应该会出这样的错:

 

  1. 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 导出对应表的建表语句即可:

 

  1. 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,无法设置。所以***我们这里可用的命令是:

 

  1. ./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000002410.page -t xxxx.sql > dumps/default/TABLENAME 2> load_cmd.sql 

把数据恢复出来以后,执行

 

  1. mysql --local-infile -uroot -p DBNAME < load_cmd.sql 

就可以把数据导进去了,记得在数据库里查询一下有没有成功,如果没有数据恢复出来,应该是其中的某些环节出了问题。

这样就成功恢复了某一个表,只要按这里***三条命令(导出建表语句、恢复数据、导入数据)重复地做下去,你就能把基本上所有的数据都恢复出来了。之所以说是 “基本上”,原因是我系统中使用了 utf8mb4 编码(为了兼容 emoji),结果是如果数据中有 emoji 的内容就会在导入数据的环节出错,暂时没有找到办法恢复这个数据。

 

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

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/272810.html<

(0)
管理的头像管理
上一篇2025-05-08 23:43
下一篇 2025-05-08 23:45

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注