MySQL innodb_force_recovery

问题

t_repository_form_answer数据量近亿级，需要增加字段，新建临时表t_repository_form_answer_tmp（增加字段），copy数据到临时表，删除原表，修改临时表名。

由于数据量过大，导致copy数据耗时太久，回滚版本未及时kill掉数据库进程，1天后发现copy进程还在，kill掉进程出现killed死锁。

SELECT * FROM information_schema.INNODB_TRX

查询trx_rows_modified数据量高达6000万，mysql在执行事务回滚操作，但是数据减小速度比较慢，同时表锁住导致表单提交答案失败。

解决方案

1. 修改mysql配置文件

[mysqld]
# 不执行事务回滚操作
innodb_force_recovery = 3

2. 重启mysql

   重启mysql后发现trx_rows_modifie数据不再变化，说明数据库不在执行事务回滚操作，但是启动程序提示operation not allowed when innodb_force_recovery > 0，因为innodb_force_recovery大于0后，可以对标进行select、create、drop操作，但insert、update或者delete这类操作是不允许的

   注：通过windows服务停止、启动mysql耗时比较久会提示异常信息，无视。可以取资源管理器结束mysql进程。

3. 删除临时表t_repository_form_answer_tmp

4. 修改innodb_force_recovery=0

5. 重启mysql，重启后trx_rows_modified会减少的很快，最终变为0

innodb_force_recovery参数介绍

参数innodb_force_recovery影响了整个Innodb存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption，Mysql数据库可能会宕机，并把错误写入错误日志中。
        但在某些情况下，可能不需要执行完整的恢复操作。例如在进行alter table操作时，这时发生意外，数据库重启时会对Innodb表执行回滚操作。对于一个大表，这需要很长时间，甚至可能是几个小时。这时可以自行恢复，例如将表删除，从备份中重新将数据导入表中，这些操作可能要快于回滚操作。

Innodb_force_recovery可以设置6个非零值：

• 1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。

• 2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。

• 3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。

• 4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。

• 5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。

• 6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。     

  备注：当设置innodb_force_recovery大于0后，可以对标进行select、create、drop操作，但insert、update或者delete这类操作是不允许的。