从ibdata1、ib_logfile1、ib_logfile0备份

Question

我无意中删除了我的文字按mysql。下面是我在我的目录中看到的日志文件列表，我希望能在那里得到一些数据。

实际上，我将第一个文件(MySQLbin.0001)转换为sql，并看到wordpress表的create语句。这让我对这样一个事实充满了希望，那就是我可能能够恢复我所有的数据。但是，我在下面的mysql二进制日志文件中运行了所有mysql命令，并且只能打开wordpress博客的一个非常旧的版本。

我可以使用ibdata1、ib_logfile1、ib_logfile0文件恢复数据吗？

Answer 1

我在同一个DB实例上的二进制日志文件中重新运行了sql语句(这给了我一个更老版本的wordpress表)

唉哟。恢复的希望有多大取决于您的表是使用MyISAM还是InnoDB存储引擎。如果MyISAM，那么..。“没有”，如果是InnoDB，那么“一些”。

旧引擎MyISAM将其数据存储在以表命名的文件中，并具有MYD扩展名，而InnoDB则将数据存储在以表命名的文件中、具有ibd扩展名的文件中，或者存储在系统表空间的ibdata1文件中，这取决于配置中innodb_file_per_table的设置。每个表的定义(列名、数据类型、索引定义)都存储在以表命名的文件中，具有frm扩展名。

ibdata1文件的较大大小表明，您可能没有启用innodb_file_per_table，如果您确实在使用没有innodb_file_per_table的InnoDB，那么以下步骤的一些变化可能会奏效：

1. 把所有东西都备份一份。
2. 设置一个单独的新MySQL服务器。
3. 将您必须使用的绑定日志应用到新服务器，以便为表定义重新创建.frm文件，然后手动修改任何表，以进行您记得在旧的绑定日志中没有考虑到的任何更改。
4. 停止新服务器。
5. 将数据目录及其.frm文件中的目录复制到旧服务器上的适当位置。
6. 如果需要的话，使用诺姆b_力_回收启动旧服务器，看看如果表定义相同的话，InnoDB将如何将.frm文件与ibdata1中的表数据(它应该这样做)配对。

既然您已经在现有服务器上创建了新的表，大概是同名的表，那么该计划成功的任何希望都可能被消除，或者大大减少到不值得尝试的程度，因为如果您尝试了，您最好的希望是看看您现在看到的是什么--您插入从二进制日志创建的表中的旧数据。

B计划是什么？借用一句恰当的话，我将引用如下：

“这是一个繁琐的过程，需要了解InnoDB的内部数据存储格式、C编程以及相当多的直觉和经验。”

http://www.percona.com/docs/wiki/innodb-data-recovery-tool:start

Percona InnoDB数据恢复工具是我能想到的唯一有意义的方法，它能让你达到你所需要的.或任何可比较的工具，假设有可比较的工具。我看不到任何简单的路..。如果你想拯救你的数据，你将不得不去“低水平”。

您已经删除了重要的文件，并且为了从第一个问题中恢复，您修改了一个可能是可挽救的剩余文件，我不完全确定InnoDB将如何处理其内部结构中的那些废弃表。数据可能还在隐藏。

不过，有一个理由让人感到乐观，那就是字符串实用程序。我提供的链接不是指向真正的GNU“字符串”实用程序，而是微软类似的半等效工具，但是这个工具的目的是显示嵌入在文件中的字符串，而内部算法认为这些字符串可能是有意义的字符串。

这有两个用途:第一，您可以尝试在您的ibdata1文件上使用它(它只读取，不应该修改)，以查看眼球告诉您在其中发现了什么。它本质上提供了一个强行窗口，用于查看文件中的原始内容，如果您在其中找到比使用binlog文件更新的文本，这是一个很好的迹象，表明使用Percona工具所花费的时间可能是值得的，因为旧的数据实际上在文件中。如果您没有看到任何您认识到的内容，那么这个方法可能会出现问题(虽然我已经证实它在Linux上使用真正的GNU“字符串”)，但是如果您看到了旧的内容而不是新的内容，那么新的内容可能会消失。

当然，“字符串”的另一种潜在用途--如果你确实看到了内容--如果它主要是你丢失的最有价值的内容--而不是配置和定制--那么你就可以使用“字符串”来提取原始内容，将其重定向到另一个文件中，然后开始一个新的wordpress安装，在那里您可以使用原始文本重新创建内容。

如果数据“那么”重要，那么Percona和SkySQL (我不隶属于这两家公司，但这两家公司似乎是MySQL空间中的两大公司)和其他公司提供付费恢复服务。