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存储引擎表执行更新操作,但是完成后不要马上提交:




  1. mysql>
  2. Query OK, 0 rows affected (0.00 sec)  
  3.  
  4. mysql> update Profile set password='';  
  5. Query OK, 9587770 rows affected (7 min 55.73 sec)  
  6. Rows matched: 9×××48  Changed: 9587770  Warnings: 0 

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




  1. [root@nineyou0-43 ~]# ps -ef | grep mysqld  
  2. 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  
  3. mysql    28045 28007 42 13:40 pts/1    00:04:23   
  4. /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql   
  5. --datadir=/usr/local/mysql/data --user=mysql
  6. --pid-file=/usr/local/mysql/data/nineyou0-43.pid   
  7. --skip-external-locking --port=3306 --socket=/tmp/mysql.sock  
  8. root     28110 26963  0 13:50 pts/11   00:00:00 grep mysqld  
  9. [root@nineyou0-43 ~]# kill -9 28007  
  10. [root@nineyou0-43 ~]# kill -9 28045 

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




  1. 090922 13:40:20  InnoDB: Started; log 
    sequence number 6 2530474615  
  2. InnoDB: Starting in background the rollback of
    uncommitted transactions  
  3. 090922 13:40:20  InnoDB: Rolling back trx with 
    id 0 5281035, 8867280 rows to undo  
  4.  
  5. InnoDB: Progress in percents: 1090922 13:40:20   
  6. 090922 13:40:20 [Note] /usr/local/mysql/bin/mysqld:
    ready for connections.  
  7. Version: '5.0.45-log'  socket: '/tmp/mysql.sock'  
    port: 3306  MySQL Community Server (GPL)  
  8. 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  
  9. InnoDB: Rolling back of trx id 0 5281035 completed  
  10. 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存储引擎是否还会执行回滚操作,查看错误日志文件,可看到:




  1. 090922 14:26:23  InnoDB: Started; log sequence
    number 7 2253251193  
  2. InnoDB: !!! innodb_force_recovery is set to 3 !!!  
  3. 090922 14:26:23 [Note] /usr/local/mysql/bin/mysqld:
    ready for connections.  
  4. 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 51591823130507 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 completedInnoDB: 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 52948722130507 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 completedInnoDB: 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


转载于:https://blog.51cto.com/huanghualiang/1195176