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这类操作是不允许的。
二、故障模拟
2.1.创建大数据量表
2.1.1.创建测试表
mysql> CREATE TABLE usertb (
-> id serial,
-> uname varchar(20) ,
-> ucreatetime datetime ,
-> age int(11)
-> ) ;
2.1.2.创建插入表存储过程
mysql> delimiter $$
mysql> create procedure test1()
-> begin
-> declare v_cnt decimal (10) default 0 ;
-> dd:loop
-> insert into usertb values
-> (null,'1','2010-01-01 00:00:00',20),
-> (null,'2','2010-01-01 00:00:00',20),
-> (null,'3','2010-01-01 00:00:00',20),
-> (null,'4','2010-01-01 00:00:00',20),
-> (null,'5','2011-01-01 00:00:00',20),
-> (null,'6','2011-01-01 00:00:00',20),
-> (null,'7','2011-01-01 00:00:00',20),
-> (null,'8','2012-01-01 00:00:00',20),
-> (null,'9','2012-01-01 00:00:00',20),
-> (null,'0','2012-01-01 00:00:00',20)
-> ;
-> commit;
-> set v_cnt = v_cnt+10 ;
-> if v_cnt = 10000000 then leave dd;
-> end if;
-> end loop dd ;
-> end;$$
Query OK, 0 rows affected (0.09 sec)
2.1.3.执行存储过程
mysql> call test1;
2.1.4.确认数据量
mysql> select count(*) from usertb;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
2.2.故障模拟
2.2.1 更新表
update usertb set age=70;
2.2.2 查看参数
mysql> show variables like '%recovery%';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+ |
| innodb_force_recovery | 0 |
+-----------------------------+-------+
2.2.3 杀死mysql进程（模拟突然宕机）
root 98943 1 0 07:45 pts/4 00:00:00 /bin/sh /u01/3306/bin/mysqld_safe --datadir=/u01/3306/data --pid-file=/u01/3306/tmp/mysqld.pid
mysql 99554 98943 24 07:45 pts/4 00:01:39 /u01/3306/bin/mysqld --basedir=/u01/3306 --datadir=/u01/3306/data --plugin-dir=/u01/3306/lib/plugin --user=mysql --log-error=/u01/3306/log/mysqld_error.log --pid-file=/u01/3306/tmp/mysqld.pid --socket=/u01/3306/mysql.sock --port=3306
[root@mysql ~]# kill -9 98943
[root@mysql ~]# kill -9 99554
2.2.4.启动mysql
观察error日志发现，在进行恢复
2018-07-12T14:53:54.060470Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-07-12T14:53:54.061908Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-07-12T14:53:54.097022Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2018-07-12T14:53:54.111544Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 4251709539
2018-07-12T14:53:54.229291Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 4256952320
2018-07-12T14:53:54.389743Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 4262195200
2018-07-12T14:53:54.518164Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 4267438080
2.2.5更改参数|innodb_force_recovery = 3 ，再次模拟发现日志如下：
2018-07-12T15:01:34.910567Z 2 [ERROR] InnoDB: innodb_force_recovery is on. We do not allow database modifications by the user. Shut down mysqld and edit my.cnf to set innodb_force_recovery=0