最近在和一个同事争论MySQL崩溃恢复中的一些常见错误时出现了一些分歧,他认为一些参数的设置会导致MySQL出现崩溃后恢复不起来的问题,但对此,我却不认同,虽然一些参数的设定会导致数据丢失,但应该不会引起数据库崩溃之后无法恢复的情况,因此,就想整理出MySQL崩溃恢复的过程来加深学习!


    MySQL崩溃恢复过程常见错误分析_第1张图片

 图一 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

  情景二:既然存在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才能启动。

  因此,参数设置不当确实会影响崩溃恢复过程!!!