2.5 InnoDB存储引擎启动、关闭与恢复

2.7 启动、关闭与恢复

• InnoDB 是 MySQL 数据库的存储引擎之一，因此 InnoDB 存储引擎的启动和关闭，更准确的是指在 MySQL 实例的启动过程中对 InnoDB 存储引擎的处理过程。
• 在关闭时，参数 innodb_fast_shutdown 影响着表的存储引擎为 InnoDB 的行为，数可取值为 0、1、2，默认值为 1。
• 0表示在 MySQL 数据库关闭时，InnoDB 需要完成所有的 full purge 和 merge insert buffer，并且将所有的脏页刷新回磁盘。这需要一些时间，有时甚至需要几个小时来完成。如果在进行 InnoDB 升级时，必须将这个参数调为 0，然后再关闭数据库。
• 1是参数 innodb_fast_shutdown 的默认值，表示不需要完成上述的 full purge 和merge insert buffer 操作，但是在缓冲池中的一些数据脏页还是会刷新回磁盘。
• 2表示不完成 full purge 和 merge insert buffer操作，也不将缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事务的丢失，但是下次 MySQL 数据库启动时，会进行恢复操作（recovery）。
• 当正常关闭 MySQL 数据库时，下次的启动应该会非常"正常"。但是如果没有正常地关闭数据库，如用 kill 命令关闭数据库，在 MySQL 数据库运行中重启了服务器，或者在关闭数据库时，将参数 innodb_fast_shutdown 设为了2 时，下次 MySOL 数据库启动时都会对 InnoDB存储引擎的表进行恢复操作。
• 参数 innodb_force_recovery 影响了整个 InnoDB存储引擎恢复的状况。该参数值默认为0，代表当发生需要恢复时，进行所有的恢复操作，当不能进行有效恢复时，如数据页发生了corruption，MySQL 数据库可能发生宕机（crash），并把错误写入错误日志中去。
• 但是，在某些情况下，可能并不需要进行完整的恢复操作，因为用户自己知道怎么进行恢复。比如在对一个表进行 alter table 操作时发生意外了，数据库重启时会对 InnoDB 表进行回滚操作，对于一个大表来说这需要很长时间，可能是几个小时。这时用户可以自行进行恢复，如可以把表删除，从备份中重新导入数据到表，可能这些操作的速度要远远快于回滚操作。
• 参数 innodb_force_recovery 还可以设置为6个非零值∶1～ 6。大的数字表示包含了前面所有小数字表示的影响。具体情况如下∶
• 1（SRV_FORCE_IGNORE_CORRUPT）∶ 忽略检查到的 corrupt 页。
• 2（SRV_FORCE_NO_BACKGROUND）∶阻止 Master Thread 线程的运行，如 Master Thread 线程需要进行 full purge 操作，而这会导致 crash。
• 3（SRV_FORCE_NO_TRX UNDO）∶不进行事务的回滚操作。
• 4（SRV_FORCE_NO_IBUF_MERGE）∶ 不进行插入缓冲的合并操作。
• 5（SRV_FORCE_NO_UNDO_LOG_SCAN）∶ 不查看撤销日志（Undo Log），InnoDB
  存储引擎会将未提交的事务视为已提交。
• 6（SRV_FORCE_NO_LOG_REDO）∶ 不进行前滚的操作。
• 需要注意的是，在设置了参数 innodb_force_recovery 大于0后，用户可以对表进行 select、create 和 drop操作，但 insert、update 和 delete 这类 DML操作是不允许的。
• 现在来做一个实验，模拟故障的发生。在第一个会话中（session），对一张接近 1 000 万行的 InnoDB存储引擎表进行更新操作，但是完成后不要马上提交;
  
• START TRANSACTION 语句开启了事务，同时防止了自动提交（auto commit）的发生，UPDATE 操作则会产生大量的 UNDO 日志（undo log）。这时，人为通过 kill 命令杀掉 MySQL 数据库服务器∶
  

通过 kill 命令可以模拟数据库的宕机操作。下次 MySQL 数据库启动时会对之前的 UPDATE 事务进行回滚操作，而这些信息都会记录在错误日志文件（默认后缀名为 err）中。如果查看错误日志文件，可得如下结果∶

• 可以看到，采用默认的策略，即将 innodb_force_recovery 设为0，InnoDB 会在每次启动后对发生问题的表进行恢复操作。通过错误日志文件，可知这次回滚操作需要回滚 8867280行记录，差不多总共进行了 9分钟。
• 再做一次同样的测试，只不过这次在启动 MySQL数据库前，将参数 innodb_force_recovery 设为3，然后观察 InnoDB存储引擎是否还会进行回滚操作。查看错误日志文件，可得∶

• 这里出现了"!!!"，InnoDB 警告已经将 innodb_force_recovery 设置为3，不会进行回滚操作了，因此数据库很快启动完成了。但是用户应该小心当前数据库的状态，并仔细确认是否不需要回滚事务的操作。