☰

从 ibdata/frm 文件恢复 mysql

tag-icon • tag-icon mysql innodb data-recovery
从 ibdata/frm 文件恢复 mysql

硬盘故障导致我尝试从“数据”文件夹的副本恢复 mysql，我转储了“大多数”内容，但缺少一些数据文件夹有 idbdata1 / 日志文件 / .frm 文件的文件夹因此，我阅读了很多关于这方面的内容，并尝试了很多方法（见下文），但无法启动服务 - 我是使用 mysql 5.5 的 Windows 用户

1）使用 innodb_force_recovery = 6 启动所有原始日志文件的服务

RESULT: 
InnoDB: Error: log file .\ib_logfile0 is of different size 0 100663296 bytes
InnoDB: than specified in the .cnf file 0 178257920 bytes!

2）删除日志文件，使用 innodb_force_recovery = 6 启动服务

RESULT:
InnoDB: Page directory corruption: infimum not pointed to
131001 19:54:14  InnoDB: Page dump in ascii and hex (16384 bytes):len 16384; hex

3）尝试使用 innodb 恢复指令http://www.chriscalender.com/?p=49但这使用 Linux，无法在我的 Windows 设置上运行 - 尽管安装了 perl

我现在陷入困境并准备致电 Percona - 欢迎提出任何想法???

***编辑

发现了 3 个月前的另一个“数据”文件夹 - 可以用此文件夹启动服务，但会出现错误

Cannot find table xxx from the internal data dictionary of innodb 
though the .frm table exists etc...

对于所有 innodb 表 - 正在谷歌搜索解决方案

答案1

MySQL 服务器生成和使用的所有文件（ibdata1、ib_logfile*、.frm、.ibd 等）都应该可以在操作系统之间互换——我从经验中知道它们可以在 Solaris 和 Linux 之间互换，但我一般尽量远离 Windows，所以我不能肯定地说...但有一种选择可能是让一个可以运行的 Linux MySQL 5.5 设置开始，然后停止它并将所有这些文件复制到 Linux 机器上以替换现有的“datadir”。

但下一步的适当措施也高度依赖于到底发生了什么……服务器是正常终止，还是反复崩溃？而且，这将取决于哪个文件导致了问题。如果是来自一个表的 .ibd 文件，那么将该文件重命名为 .ibd 以外的其他名称应该可以让 MySQL 跳过该文件并继续处理下一个。

如果您不使用，innodb_file_per_table那么您的所有鸡蛋都放在一个非常脆弱的篮子里，ibdata1。

如果您启用了二进制日志记录并且只有稍微陈旧的备份，那么也可以在另一台机器上恢复备份并播放二进制日志以恢复其他数据。

根据您的一般系统管理专业知识水平、备份的可用性以及数据的紧急性和价值，致电 Percona 或 SkySQL 可能是最好的计划。

相关内容