概述

數據庫系統與文件系統很大的區別在于數據庫能保證操作的原子性，一個操作要么不做要么都做，即使在數據庫宕機的情況下，也不會出現操作一半的情況，這個就需要數據庫的日志和一套完善的崩潰恢復機制來保證。下面簡單介紹一下InnoDB的崩潰恢復流程。 

[[276536]]

相關概念

lsn: 可以理解為數據庫從創建以來產生的redo日志量，這個值越大，說明數據庫的更新越多，也可以理解為更新的時刻。此外，每個數據頁上也有一個lsn，表示最后被修改時的lsn，值越大表示越晚被修改。比如，數據頁A的lsn為100，數據頁B的lsn為200，checkpoint lsn為150，系統lsn為300，表示當前系統已經更新到300，小于150的數據頁已經被刷到磁盤上，因此數據頁A的最新數據一定在磁盤上，而數據頁B則不一定，有可能還在內存中。

redo日志: 現代數據庫都需要寫redo日志，例如修改一條數據，首先寫redo日志，然后再寫數據。在寫完redo日志后，就直接給客戶端返回成功。這樣雖然看過去多寫了一次盤，但是由于把對磁盤的隨機寫入(寫數據)轉換成了順序的寫入(寫redo日志)，性能有很大幅度的提高。當數據庫掛了之后，通過掃描redo日志，就能找出那些沒有刷盤的數據頁(在崩潰之前可能數據頁僅僅在內存中修改了，但是還沒來得及寫盤)，保證數據不丟。

undo日志: 數據庫還提供類似撤銷的功能，當你發現修改錯一些數據時，可以使用rollback指令回滾之前的操作。這個功能需要undo日志來支持。此外，現代的關系型數據庫為了提高并發(同一條記錄，不同線程的讀取不沖突，讀寫和寫讀不沖突，只有同時寫才沖突)，都實現了類似MVCC的機制，在InnoDB中，這個也依賴undo日志。為了實現統一的管理，與redo日志不同，undo日志在Buffer Pool中有對應的數據頁，與普通的數據頁一起管理，依據LRU規則也會被淘汰出內存，后續再從磁盤讀取。與普通的數據頁一樣，對undo頁的修改，也需要先寫redo日志。

檢查點: 英文名為checkpoint。數據庫為了提高性能，數據頁在內存修改后并不是每次都會刷到磁盤上。checkpoint之前的數據頁保證一定落盤了，這樣之前的日志就沒有用了(由于InnoDB redolog日志循環使用，這時這部分日志就可以被覆蓋)，checkpoint之后的數據頁有可能落盤，也有可能沒有落盤，所以checkpoint之后的日志在崩潰恢復的時候還是需要被使用的。InnoDB會依據臟頁的刷新情況，定期推進checkpoint，從而減少數據庫崩潰恢復的時間。檢查點的信息在第一個日志文件的頭部。

崩潰恢復: 用戶修改了數據，并且收到了成功的消息，然而對數據庫來說，可能這個時候修改后的數據還沒有落盤，如果這時候數據庫掛了，重啟后，數據庫需要從日志中把這些修改后的數據給撈出來，重新寫入磁盤，保證用戶的數據不丟。這個從日志中撈數據的過程就是崩潰恢復的主要任務，也可以成為數據庫前滾。當然，在崩潰恢復中還需要回滾沒有提交的事務，提交沒有提交成功的事務。由于回滾操作需要undo日志的支持，undo日志的完整性和可靠性需要redo日志來保證，所以崩潰恢復先做redo前滾，然后做undo回滾。

數據庫崩潰恢復過程

下面看一下數據庫崩潰恢復過程。整個過程都在引擎初始化階段完成(innobase_init)，其中最主要的函數是innobase_start_or_create_for_mysql，innodb通過這個函數完成創建和初始化，包括崩潰恢復。首先來介紹一下數據庫的前滾。

崩潰恢復相關參數解析

1、innodb_fast_shutdown:

innodb_fast_shutdown = 0。這個表示在MySQL關閉的時候，執行slow shutdown，不但包括日志的刷盤，數據頁的刷盤，還包括數據的清理(purge)，ibuf的合并，buffer pool dump以及lazy table drop操作(如果表上有未完成的操作，即使執行了drop table且返回成功了，表也不一定立刻被刪除)。 innodb_fast_shutdown = 1。這個是默認值，表示在MySQL關閉的時候，僅僅把日志和數據刷盤。 innodb_fast_shutdown = 2。這個表示關閉的時候，僅僅日志刷盤，其他什么都不做，就好像MySQL crash了一樣。 這個參數值越大，MySQL關閉的速度越快，但是啟動速度越慢，相當于把關閉時候需要做的工作挪到了崩潰恢復上。另外，如果MySQL要升級，建議使用第一種方式進行一次干凈的shutdown。

2、innodb_force_recovery

這個參數主要用來控制InnoDB啟動時候做哪些工作，數值越大，做的工作越少，啟動也更加容易，但是數據不一致的風險也越大。當MySQL因為某些不可控的原因不能啟動時，可以設置這個參數，從1開始逐步遞增，知道MySQL啟動，然后使用SELECT INTO OUTFILE把數據導出，盡最大的努力減少數據丟失。 innodb_force_recovery = 0。這個是默認的參數，啟動的時候會做所有的事情，包括redo日志應用，undo日志回滾，啟動后臺master和purge線程，ibuf合并。檢測到了數據頁損壞了，如果是系統表空間的，則會crash，用戶表空間的，則打錯誤日志。

innodb_force_recovery = 1。如果檢測到數據頁損壞了，不會crash也不會報錯(buf_page_io_complete)，啟動的時候也不會校驗表空間第一個數據頁的正確性(fil_check_first_page)，表空間無法訪問也繼續做崩潰恢復(fil_open_single_table_tablespace、fil_load_single_table_tablespace)，ddl操作不能進行(check_if_supported_inplace_alter)，同時數據庫也被不能進行寫入操作(row_insert_for_mysql、row_update_for_mysql等)，所有的prepare事務也會被回滾(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)。這個選項還是很常用的，數據頁可能是因為磁盤壞了而損壞了，設置為1，能保證數據庫正常啟動。 innodb_force_recovery = 2。除了設置1之后的操作不會運行，后臺的master和purge線程就不會啟動了(srv_master_thread、srv_purge_coordinator_thread等)，當你發現數據庫因為這兩個線程的原因而無法啟動時，可以設置。

innodb_force_recovery = 3。除了設置2之后的操作不會運行，undo回滾數據庫也不會進行，但是回滾段依然會被掃描，undo鏈表也依然會被創建(trx_sys_init_at_db_start)。srv_read_only_mode會被打開。

innodb_force_recovery = 4。除了設置3之后的操作不會運行，ibuf的操作也不會運行(ibuf_merge_or_delete_for_page)，表信息統計的線程也不會運行(因為一個壞的索引頁會導致數據庫崩潰)(info_low、dict_stats_update等)。從這個選項開始，之后的所有選項，都會損壞數據，慎重使用。

innodb_force_recovery = 5。除了設置4之后的操作不會運行，回滾段也不會被掃描(recv_recovery_rollback_active)，undo鏈表也不會被創建，這個主要用在undo日志被寫壞的情況下。

innodb_force_recovery = 6。除了設置5之后的操作不會運行，數據庫前滾操作也不會進行，包括解析和應用(recv_recovery_from_checkpoint_start_func)。

總結

InnoDB實現了一套完善的崩潰恢復機制，保證在任何狀態下(包括在崩潰恢復狀態下)數據庫掛了，都能正常恢復，這個是與文件系統比較大的差別。