MySQL的InnoDB数据文件损坏如何修复

因为被破坏的地方只在索引的部分，所以当使用innodb_force_recovery = 1运行InnoDB时， *** 作如下：

执行check，repair table 都无效

alter table email_status engine =myisam#也报错拦氏了，因为模式是innodb_force_recovery =1。

ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)

建立一张表：create table email_status_bak #和原表结构一样，只是把INNODB改成了MYISAM。把数据导进去insert into email_status_bak select * from email_status

删除掉原表：

drop table email_status

注释掉innodb_force_recovery 之后，重启。

重命名：

rename table edm_email_status_bak to email_status

最后该回存储引擎

alter table edm_email_status engine = innodb

总结：

这里的一个重要知识点就是 对 innodb_force_recovery 参数的理解了，要是遇到数据损坏甚至是简吵散其他的损坏。碰贺可能上面的方法不行了，需要尝试另一个方法：insert into tb select * from ta limit X；甚至是dump出去，再load回来。

Windows上安装了XMAPP-controller之后间歇性出现MySQL无法启动，查看日之后发现是innodb的报错，报错信息如下：

度娘上各种答案无法解决，后来直接看官方文档，直接上解决方案：

踩坑指南 - - *** 作配置前需要做这些 *** 作：

1、配置my.cnf 配置innodb_force_recovery = 1 到 6 试到正确为止，重启MySQL

2、导出数据脚本 mysqldump -uroot -p123456 test >test.sql 导出SQL脚本。或者用Navicat将所有数据库/表导入到其他服务器的数据库尺告差中。 注意：这里的数据一定要备份成功。然后删除原数据库中的数据。

3、删除ib_logfile0、ib_logfile1、ibdata1 备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件，然后将这三个文件删除

4、配置my.cnf 将my.cnf中innodb_force_recovery 这行配置删除或者配置为innodb_force_recovery = 0，重启MySQL服务

5、将数据导入MySQL数据库 mysql -uroot -p123456 test <test.sql

或者用Navicat将备份的数据导入到数陵皮据库中。 如果友历在导入数据过程中发生tablespace不存在的问题，请删除data目录相应database下的文件。

经常性备份，如果binlog在的话，试试看……

- 恢复策略

前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时梁袜如,这些事务要进行特殊的的处理.有2中不同的恢复策略：

A. 进行恢复时，只重做已经提交了的事务。

B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务。

- InnoDB存储引擎的恢复机制

MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储好燃引擎中的恢复机制有几个特点：

A. 在重做Redo Log时，并不关心事务性。 恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要 *** 作的数据的一部分。

B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的 *** 作也会记录到redo log中。这样undo log就可以像数据一样缓存起来，而不橡启用再redo log之前写入磁盘了。

包含Undo Log *** 作的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert …>

记录3: <trx2, Undo log insert <undo_update …>>

记录4: <trx2, update …>

记录5: <trx3, Undo log insert <undo_delete …>>

记录6: <trx3, delete …>

C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？确实是这样。同时Innodb也会将事务回滚时的 *** 作也记录到redo log中。回滚 *** 作本质上也是对数据进行修改，因此回滚时对数据的 *** 作也会记录到Redo Log中。

一个回滚了的事务的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert A…>

记录3: <trx1, Undo log insert <undo_update …>>

记录4: <trx1, update B…>

记录5: <trx1, Undo log insert <undo_delete …>>

记录6: <trx1, delete C…>

记录7: <trx1, insert C>

记录8: <trx1, update B to old value>

记录9: <trx1, delete A>

一个被回滚了的事务在恢复时的 *** 作就是先redo再undo，因此不会破坏数据的一致性.

- InnoDB存储引擎中相关的函数

Redo: recv_recovery_from_checkpoint_start()

Undo: recv_recovery_rollback_active()

Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

---