数据库运维之InnoDB存储引擎表损坏修复方法

InnoDB存储引擎表的损坏可能是多种因素导致的，比如服务器断电、系统崩溃、硬盘损坏、写数据过程中mysqld进程被kill掉。

严重的损坏可能导致无法执行SELECT
语句或InnoDB
引擎意外退出，甚至导致InnoDB
向前滚动恢复崩溃。在这种情况下，我们可以使用innodb_force_recovery
选项强制 InnoDB 存储引擎启动，同时阻止后台操作运行，以便使用SELECT ... INTO OUTFILE
从数据库中转储表中数据，以这种方式获得的大部分数据都是完好无损的。

例如，将以下行添加到选项文件的 [mysqld] 部分，然后再重新启动服务器：

 [mysqld]
 innodb_force_recovery = 1

注意：

• 在强制 InnoDB 恢复时，应始终从 innodb_force_recovery=1
  开始，并且仅在必要时增加值。在此之前，请确保做好数据库的备份副本，以便需要重建数据库。

• innodb_force_recovery
  设置为 4 或以上可能会永久损坏数据文件，只有在数据库的物理副本测试设置成功后，才能在生产环境使用4或更大的值。

innodb_force_recovery
的默认值是0（正常启动，不使用恢复模式），可配置的值为1~6，较大的值会包含较小的值的所有功能。举个例子，配置为3，那么会包含选项1、2的所有功能。

当innodb_force_recovery
配置为 3 或更小的值可以转储表，数据相对安全，因为只有损坏的单页上的某些数据丢失。值为 4 或更高值会比较危险，因为数据文件可能会永久损坏。值为6时，因为数据页处于废弃状态，这可能会给 B 树和其他数据库结构带来更多的破坏。为了安全，innodb_force_recovery>0
时禁止使用INSERT、DELETE、UPDATE
操作。innodb_force_recovery>=4
时InnoDB进入只读模式。

innodb_force_recovery选项：

• 1 (SRV_FORCE_IGNORE_CORRUPT)
       

  检查到的错误页，仍允许服务运行。在转储表时会跳过损坏的索引和页。

• 2 (SRV_FORCE_NO_BACKGROUND)
   

  阻止主线程和任何清理线程运行，执行清理操作时可能会引起crash。

• 3 (SRV_FORCE_NO_TRX_UNDO)
     

  不执行事务回滚。

• 4 (SRV_FORCE_NO_IBUF_MERGE)
  

  不执行 change buffer
  的合并操作。此值可能会永久损坏数据文件。使用此值后，将删除并重建所有二级索引且将 InnoDB 设置为只读。   

• 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
  

  启动数据库时不查看undo log
  ，InnoDB将未提交的事务视为已提交。此值可能会永久损坏数据文件。

• 6 (SRV_FORCE_NO_LOG_REDO)
   

  redo log
  不做前滚操作。

通过innodb_force_recovery
启动后，可进行如下操作：

1. 导出数据

    select * into outfile '/tmp/outfile.txt' from tb1;

2. 删除损坏的表

    drop table tb1;

3. 创建新表

    create table `tb1` (id varchar(20));

4. 导入数据

    LOAD DATA local INFILE '/tmp/outfile.txt' IGNORE INTO TABLE tb1;

如果表数据损坏导致无法转储数据，可以尝试加上ORDER BY primary_key
，这个操作可以跳过表中损坏的部分转储数据。如果数据结构已经损坏，可能无法使用复杂的查询语句，只能通过SELECT * FROM tb1
来保存数据。

欢迎大家关注我

如果有问题可以后台留言交流。

有问必答，共同进步