记一次揪心的MySQL数据恢复过程

先说下背景，公司其中一个项目所有服务都部署在客户的机房内，机房较小，没有UPS。其中一个MySQL实例(单机，无主从，windows server 2008，MySQL5.6.19)存放大量的日志数据，每天几十G的数据，定期清除(保存大概四个月的数据)，由于硬盘空间不够，所以没有定期的备份。机房突然断电，启动MySQL server，当时没有注意错误日志，但是访问其中一个表时，server自动挂掉，这才意识到数据库可能因为突然掉电导致无法正常启动，然后查看错误日志：

2017-10-12 18:05:22 bd0 InnoDB: Error: page 756 log sequence number 786184012016
InnoDB: is in the future! Current system log sequence number 786183991367.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.

根据错误提示：数据文件的LSN比redo log的LSN要大，当系统尝试使用Redo Log去修复数据页面的时候，发现Redo Log LSN比数据页面还小，所以导致错误。数据页的LSN在一般情况下，都是小于Redo Log的，因为在事物提交或按照 innodb_trx_commit 设置的方式提交时，先将事物顺序写入Redo Log ， 然后后台线程按照 max_prt_dirty_page 参数设置的比例刷新或当系统检测到当10秒内系统会执行刷新脏页操作，所以，数据页的LSN正常情况下永远会比Redo Log 的LSN 小。

因此通过设置innodb_force_recovery大于0 ，重启数据库服务，导出重要的数据，重建数据库。
首先了解下innodb_force_recovery 设置为不同值对启动数据库服务过程的影响,大的数字包含前面所有数字的影响。
- 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存储引擎会将未提交的事务视为已提交。

当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。当然即使innodb_force_recovery>0 ，你也可以DROP或CREATE表。

以此设置innodb_force_recovery为1到6，启动服务使用mysqldump备份数据库，每次都提示同样的错误：

mysqldump -uuser -ppasswd --skip-ext
ended_insert --hex-blob -y -n -t --routines --events --triggers --databases db_name >> "d:/db_name.sql"
Warning: Using a password on the command line interface can be insecure.
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping
 table `tb_name` at row: 50548

然后执行:

select id from tb_name limit 50548,1;

同样提示：

ERROR