不同修复模式的功用

对于InnoDB引擎来说，拥有自动恢复机制。在通常情况下，当服务器出现宕机时，InnoDB是可以在重启时自动修复错误的。在某些情况下，因为出现的异常情况也会导致其无法进行修复。为此，可以通过设置“innidb_force_recovery”参数，来进行人工修复。该参数可以设置不同的值，对应不同的修复级别。在默认情况下，该参数的值为0，表示不启用。如果对其改变的话，数据表就会处于只读状态，而且只能执行基本的Select等语句，不能附加Where，Order BY等参数。因为数据表处于恢复状态，不能进行插入删除等修改操作。如果将其设置为1，例如“innodb_force_recovery=1”表示即使发现了损坏，也会让服务继续运行，这对于数据的备份和转存当前的数据很有用。

这适用于数据本身没有大的损坏，在可以正常读取数据的情况下，将数据备份出来，通过重新创建同样的数据库，并将数据恢复进来。该模式可以满足一般情况下的数据恢复之用。如果将其设置为2，例如“innodb_force_recovery=2”，表示在主线程和任何清除线程运行时，可以防止因为清除操作导致服务器宕机的发生。根据以上分析，在InnoDB引擎运行时，会执行各种循环，在其中会执行清除操作，将缓存中的数据写入磁盘，同时可以校验磁盘文件（例如“ib_logfile”,“*.ibd”文件等日志，索引文件）的结构的完整性，如果结构出现损坏，就会导致清除操作发生问题，甚至导致数据库崩溃。利用上述参数值，可以禁止执行后台循环，来避免上述危险的发生。

上述两种模式，在一般情况下不会导致数据的丢失，而其余的模式就容易导致数据不完整性的发生。如果设置为3，例如“innodb_force_recovery=3”，表示恢复后不回滚事务。当在当前数据库中进行了一些事务性的操作，在事务没有正常关闭的情况下，对于该模式来说，会强制性认为事务已经关闭，而且不会回滚未关闭的事务，这很容易导致当前数据库中的数据发生错误或者意外改变。如果设置为4，例如“innodb_force_recovery=4”，表示如果插入到缓冲区中的合并操作导致数据库崩溃，则禁止执行该操作。使用该模式，可能造成索引出现问题。解决方式是先导出数据，之后重新用相同的数据库恢复数据，然后重建索引。

如果将其设置为5，例如“innodb_force_recovery=5”，表示启动数据库时忽略撤销日志，InnoDB引擎将未完成的事务视作已完成，该模式不执行Redo日志扫描和比对。如果设置为6，表示在启动数据库时，忽略与恢复相关的前滚日志。即如果在宕机时，“ib_logfile1”等日志文件中数据发生损坏，造成无法读取日志或者读取的是错误的信息，使用该模式将其忽略。这样，在重启之后，一些需要重做的事务操作被忽略，可能会导致数据的丢失。因为在重做日志中存放了多条日志信息，如果其中某条日志信息出现损坏，那么所有的日志信息都会被抛弃，导致丢失相关的事务操作，自然会出现数据的丢失。