MySQL启动、关闭与恢复 参数介绍

InnoDB存储引擎是MySQL的存储引擎之一，因此InnoDB存储引擎的启动和关闭更准确地是指在MySQL实例的启动过程中InnoDB表存储引擎的处理过程。
在关闭时，参数innodb_fast_shutdown影响着表的存储引擎为InnoDB的行为。该参数可取值为0、1、2。

0代表当MySQL关闭时，InnoDB需要完成所有的full purge和merge insert buffer操作，这会需要一些时间，有时甚至需要几个小时来完成。如果在做InnoDB plugin升级，通常需要将这个参数调为0，然后再关闭数据库。
1是该参数的默认值，表示不需要完成上述的full purge和merge insert buffer操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。
2表示不完成full purge和merge insert buffer操作，也不将缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事务会丢失，但是MySQL数据库下次启动时，会执行恢复操作（recovery）。

当正常关闭MySQL数据库时，下一次启动应该会很正常。但是，如果没有正常地关闭数据库，如用kill命令关闭数据库，在MySQL数据库运行过程中重启了服务器，或者在关闭数据库时将参数innodb_fast_shutdown设为了2，MySQL数据库下次启动时都会对InnoDB存储引擎的表执行恢复操作。
参数innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption，MySQL数据库可能会宕机，并把错误写入错误日志中。
但是，在某些情况下，我们可能并不需要执行完整的恢复操作，我们自己知道如何进行恢复。比如正在对一个表执行alter table操作，这时意外发生了，数据库重启时会对InnoDB表执行回滚操作。对于一个大表，这需要很长时间，甚至可能是几个小时。这时我们可以自行进行恢复，例如可以把表删除，从备份中重新将数据导入表中，这些操作的速度可能要远远快于回滚操作。
innodb_force_recovery还可以设置为6个非零值：1～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）：不查看撤销日志（Undo Log），InnoDB存储引擎会将未提交的事务视为已提交。
6（SRV_FORCE_NO_LOG_REDO）：不执行前滚的操作。
需要注意的是，当设置参数innodb_force_recovery大于0后，可以对表进行select、create、drop操作，但insert、update或者delete这类操作是不允许的。

下面是实验，模拟故障的发生。在第一会话中，对一张接近1 000W行的InnoDB存储引擎表执行更新操作，但是完成后不要马上提交：

mysql> start transaction;  Query OK, 0 rows affected (0.00 sec)   mysql> update Profile set password='';  Query OK, 9587770 rows affected (7 min 55.73 sec)  Rows matched: 9999248  Changed: 9587770  Warnings: 0

start transaction语句开启了事务，同时防止了自动提交的发生，update操作则会产生大量的回滚日志。这时，我们人为地kill掉MySQL数据库服务器。

[root@nineyou0-43 ~]# ps -ef | grep mysqld  root     28007     1  0 13:40 pts/1
00:00:00 /bin/sh ./bin/mysqld_safe         -
-datadir=/usr/local/mysql/data --pid-file=/usr
/local/mysql/data/nineyou0-43.pid  mysql    28045 28007 42 13:40 pts/1    00:04:23   /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql   --datadir=/usr/local/mysql/data --user=mysql   --pid-file=/usr/local/mysql/data/nineyou0-43.pid   --skip-external-locking --port=3306 --socket=/tmp/mysql.sock  root     28110 26963  0 13:50 pts/11   00:00:00 grep mysqld  [root@nineyou0-43 ~]# kill -9 28007  [root@nineyou0-43 ~]# kill -9 28045

通过kill命令，我们人为地模拟了一次数据库宕机故障，当MySQL数据库下次启动时会对update的这个事务执行回滚操作，而这些信息都会记录在错误日志文件中，默认后缀名为err。如果查看错误日志文件，可得到如下结果：

090922 13:40:20  InnoDB: Started; log
sequence number 6 2530474615  InnoDB: Starting in background the rollback of
uncommitted transactions  090922 13:40:20  InnoDB: Rolling back trx with
id 0 5281035, 8867280 rows to undo   InnoDB: Progress in percents: 1090922 13:40:20   090922 13:40:20 [Note] /usr/local/mysql/bin/mysqld:
ready for connections.  Version: '5.0.45-log'  socket: '/tmp/mysql.sock'
port: 3306  MySQL Community Server (GPL)  2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
89 90 91 92 93 94 95 96 97 98 99 100  InnoDB: Rolling back of trx id 0 5281035 completed  090922 13:49:21  InnoDB: Rollback of non-prepared
transactions completed

可以看到，如果采用默认的策略，即把innodb_force_recovery设为0，InnoDB会在每次启动后对发生问题的表执行恢复操作，通过错误日志文件，可知这次回滚操作需要回滚
8 867 280行记录，总共耗时约9分多钟。
我们做再做一次同样的测试，只不过在启动MySQL数据库前将参数innodb_force_ recovery设为3，然后观察InnoDB存储引擎是否还会执行回滚操作，查看错误日志文件，可看到：

090922 14:26:23  InnoDB: Started; log sequence
number 7 2253251193  InnoDB: !!! innodb_force_recovery is set to 3 !!!  090922 14:26:23 [Note] /usr/local/mysql/bin/mysqld:
ready for connections.  Version: '5.0.45-log'  socket: '/tmp/mysql.sock'
port: 3306  MySQL Community Server (GPL)

这里出现了“！！！”，InnoDB警告你已经将innodb_force_recovery设置为3，不会进行undo的回滚操作了。因此数据库很快启动完成，但是你应该很小心当前数据库的状态，并仔细确认是否不需要回滚操作。
####################################################
set global innodb_fast_shutdown=2 ; innodb_force_recovery=0
InnoDB: Log scan progressed past the checkpoint lsn 47616297
130507 23:30:33 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 51591823
130507 23:30:33 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 3679, file name ./mysql-bin.000020
130507 23:30:33 InnoDB: Waiting for the background threads to start
130507 23:30:34 InnoDB: 1.1.8 started; log sequence number 51591823

set global innodb_fast_shutdown=2 ; update后 修改配置文件innodb_force_recovery=3 后重启mysql
innoDB: Doing recovery: scanned up to log sequence number 52948722
130507 23:49:15 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2969, file name ./mysql-bin.000025
130507 23:49:15 InnoDB: Waiting for the background threads to start
130507 23:49:16 InnoDB: 1.1.8 started; log sequence number 52948722
130507 23:49:16 InnoDB: !!! innodb_force_recovery is set to 3 !!!
130507 23:49:16 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306