最近在和一个同事争论MySQL崩溃恢复中的一些常见错误时出现了一些分歧，他认为一些参数的设置会导致MySQL出现崩溃后恢复不起来的问题，但对此，我却不认同，虽然一些参数的设定会导致数据丢失，但应该不会引起数据库崩溃之后无法恢复的情况，因此，就想整理出MySQL崩溃恢复的过程来加深学习！
图一 mysql WAL过程
在正常情况下，数据写入会先写入redo_buffer_pool,然后在写入redo_log_file，这中间如果由于参数设置不当，可能会发生丢失，但不影响主机的崩溃恢复，但有以下两种情况会影响实例的崩溃恢复过程；
情景一：当主机宕机时，LSN还没有同步写入到FILE_HEADER的FIL_PAGE_FILE_FLUSH_LSN中，导致记录LSN值和Log file header记录log_checkpoint_lsn中记录的LSN不一致，理论上此时FIL_PAGE_FILE_FLUSH_LSN<log_checkpoint_lsn;此时进行崩溃恢复，将进行会重做redo_file中的差值，实现崩溃恢复，根据page的LSN进行前滚操作；
情景二：既然存在FIL_PAGE_FILE_FLUSH_LSN>log_checkpoint_lsn,这种情况会不会存在呢，确实会存在，当脏页的刷新进度大于写入redo_log_file的进度这种情况就存在了，因为刷新redo_log_file和刷新page之间并不互相干扰，因此，innodb_flush_log_at_trx_commit值确实会产生会导致FIL_PAGE_FILE_FLUSH_LSN>log_checkpoint_lsn情况出现，这种情况进行崩溃恢复就会出现比较经典的错误：ERROR:page xxx log sequence number xxx is in the futher!
表名现在page的LSN值是大于redo_log_file的LSN的，导致无法进行回滚，这时候只能加force_innodb_recovery才能启动。
因此，参数设置不当确实会影响崩溃恢复过程！！！
本文出自 “11869724” 博客，请务必保留此出处http://11879724.blog.51cto.com/11869724/1872928
原文地址：http://11879724.blog.51cto.com/11869724/1872928
