数据库服务器不支持innodb存储引擎,MySQL InnoDB存储引擎表损坏恢复指南

目的

故障排除步骤

适用于：

MySQL服务器版本

5.0至5.7[5.0版到5.7]

A 第一反应

A.1 停止，备份，重启

停止MySQL 服务器。如果它已经下线或崩溃，跳到步骤 2。

代码：

/etc/init.d/mysqld stop

这里的目的是要冻结数据和表文件的当前状态，这样就没有新的写入发生，并且我们能创建文件副本，而无需注意文件更改会导致数据不一致，或存储信息的丢失。

2.如果不是整个MySQL数据目录，备份您的数据和日志文件。

代码：

mkdir /root/innodb.bak (or backup path of your choice)

cd /var/lib/mysql (or alternate data directory, if con figured)

dd if=ibdata1 of=ibdata1.bak conv=noerror

cp -p ./ibdata* /root/innodb.bak/

cp -p ./ib_log* /root/innodb.bak/

首先，你创建了存放任何文件副本的目录，然后你在/var/lib/mysql(或你的数据目录)中创建了ibdata1 文件的本地备份，还有ibdata和ib_logfiles的备份到你的备份目录。我喜欢同时使用dd和cp创建(多个)ibdata文件的副本，因为两个工具的性质不同。 Dd工具复制原始文件，而CP复制文件内容到一个新的文件。我没有遇到过任何情况中这是恢复成功的关键，但这仍是我的习惯，我认为这绝不是一个坏习惯。

理想情况下，特别当你还没有备份时，如果可能的话，你最好立即尝试创建你的数据目录的完整副本。

命令:

cp -Rp /var/lib/mysql{,.orig}

我知道这可能过于费时或对一些的紧急情况不太实际，因此，如果这不可行，至少数据文件和InnoDB数据库目录应该提供一些能回退的数据。

3.备份你的InnoDB数据库文件夹

假设你没有备份完整的MySQL数据目录，你最好还是确保包含InnoDB表的任何数据库都有各自的备份的文件夹。如果你不知道哪个数据库包含InnoDB表，可以使用像这样的命令检查包含的.ibd文件，并将它们复制到备份文件夹(在这个例子中/root/innodb.bak是额外的目录，如果你的DATADIR不是默认的，则需要在一开始更新变量)：

代码：

DATADIR=/var/lib/mysql; find $DATADIR -type f -name *.ibd | awk -F/ '{print $(NF-1)}' | sort | uniq |

xargs -I {} cp -Rp $DATADIR/{} /root/innodb.bak

4.启动MySQL服务器(如果可以的话)

此时将MySQL重新联网是安全的，如果你能这样做而不导致崩溃。如果你能使其联网，接下来就启动MySQL服务，然后执行mysqldump，我建议如下(你可以将这些转储至/root以外的其他路径，如果你愿意记得你的选择)：

Code:

/etc/init.d/mysql start

mysqldump --single-tran saction -AER > /root/dump_wtrans.sql

mysqldump -AER > /root/dump.sql

Dumping it with singletransaction flag creates the dump in, go figure, a single transaction, which prevents locking on the database, and may help if you’re running a 100% InnoDB environment so to be safe, particularly if you’re not sure, I recommend running both.

以singletransaction标识转储它在单个事务转储数据，go figure，这能防止在数据库上的锁，如果你在运行100% InnoDB环境也会安全，特别是你不能确定的情况下，我推荐两个都运行。

一定要检查你的SQL转储内容，以确保数据实际存在。有一些情况中，如果数据由于任何原因无法访问，那只有表结构会存在。尤其当在使用singletransaction，你操作的数据库经常运行ALTER TABLE命令的时候。如果在一个表中mysqldump与ALTER TABLE一致，可能只有结构。 (详细讨论在MySQL的错误报告＃71017(BUG17862905))

注意：如果你在处理文件系统损坏，尝试并将这些文件备份到另一个可用的磁盘驱动(如果可以，甚至备份到一个安全的远程主机上)

A.2 如果MySQL崩溃

如果MySQL崩溃并拒绝重启，那这很可能是你此时最关心的问题。当然你在想让它在线用于生产，但最重要的是，MySQL在线可以让你得到真正的MySQL数据转储，这样可以最大限度地减少永久丢失数据的机会，并有助于修复可能损坏的表。

由于InnoDB的ACID合规性(MySQL的:: MySQL 5.6参考手册:: 14.2.1 MySQL和ACID模型)，它坚持严格的数据一致性标准。这实际上意味着，如果它遇到数据的任何问题，它遵循严格的数据一致性标准。这实质上意味着，如果遇到数据的任何问题，它几乎总是使MySQL崩溃以防止进一步的一致性问题。从理论上讲，这是一件好事，但实际上，非计划的停机时间从来都不是一件好事。

不过使用innodb_force_recovery选项通常可以帮助至少让MySQL回到可访问状态。也就是说，了解它的运行原因，以及如何小心使用它是个好主意。

使用 innodb_force_recovery

当 InnoDB遇到问题时，它已经尝试默认下的基本恢复步骤，但更多的时候，你需要在你的/etc/my.cnf文件这添加innodb_force_recovery设置来帮助它。这指示InnoDB在恢复模式下启动，告诉它跳过InnoDB启动过程中，通常是崩溃发生的各种部分。你最好在一开始设置最低值，1，并且只有在需要时增加，最高值是6。此设置在你的my.cnf文件的[mysqld]部分输入，在示例中显示：

代码：

[mysqld]

innodb_force_recovery = 1

你还可以运行以下单行命令来将其自动添加到你的/etc/my.cnf文件的正确部分(在一开始时，将“mode=”变量更改为任何你想用的模式)：

代码：

mode=1; sed -i "/^\[mysqld\]/{N;s/$/\ninnodb_force_recovery=$mode/}" /etc/my.cnf

然后，一旦你准备把你的服务器返回到默认模式，你可以通过以下命令删除innodb_force_recovery行：

代码：

sed -i '/innodb_force_recovery/d' /etc/my.cnf

此配置选项不应被用作使你的服​​务器联网的长期，或甚至中期的解决方案。如果你的服务器只能在innodb_force_recovery启用时联网，那在你的服务器上还是有需要处理的重要问题。如果innodb_force_recovery被闲置的活动时间过长，在服务器上可能会造成更多的问题，特别当选项设置为高值(将innodb_force_recovery长时间设为6没什么很好的理由)。这种模式完全是暂时的，仅用于恢复的目的。

以下是对每种模式的简短概要(每一种模式还复合自身，这意味着更高的值包括所有的低值的功能)：

Mode 1当遇到损坏页时，不使 MySQL 崩溃

Mode 2不运行后台操作

Mode 3不会尝试回滚事务

Mode 4不计算统计数据或应用存储/缓冲的变化

Mode 5在启动过程中不查看撤消日志

Mode 6在启动时不从重做日志(ib_logfiles)前滚

因此，如果你的MySQL服务器以模式3而不是模式2启动，崩溃与事务回滚过程有关是安全的假设。另外，要注意在MySQL5.6.15中，模式4和6将会把MySQL设为只读模式。

如果您已经试过所有innodb_force_recovery模式，但仍然由于InnoDB错误崩溃，下一步最好就是尝试并收集有关导致崩溃的原因的其他信息。

B 识别问题

InnoDB的问题多种原因，虽然通常用于概括大部分问题的“corruption”术语了常不准确，但试图找出你所面对的具体问题总是一个好主意。

B.1 检查日志

如果你怀疑InnoDB表或数据库被损坏，很可能是因为你发现受到损坏的数据，不存在数据，或者MySQL的服务拒绝启动。对于任何一种情况，你要首先查看的是MySQL错误日志。在通常的设置中，这是在/ var/ lib/mysql/中，而文件是你的主机名与.err后缀。

这里是拉出日志最后200行的快速命令，如果你不知道主机名，或不想完整输出(如果不是默认的，将数据目录替换为你自己的)：

代码：

tail -200 /var/lib/mysql/`hostname`.err

这执行hostname命令，并使用返回的字符串代替`hostname`，这是在命令行中的反引号的功能。

在这里你可能还会看到几件事情，可以帮助你pin下你遇到的损坏类型，如果有的话。在本指南中，我会涵盖在页损坏，日志序列号问题和数据字典的问题中最常见的三种损坏问