MySQL在啟動的時候，會進行前滾（利用redo log實現）和回滾（利用undo log和bin log實現）事物，來保證與前一次資料庫服務關閉前的資料版本的最終一致性。

Crash Recovery的過程，可查閱參考文件一。

我們知道，不同的落盤機制影響著redo、undo、binlog以及資料本身的重新整理策略。

1、Redo log

innodb_log_buffer_size控制著redo log的緩衝池大小，執行緒：master therad、引數：innodb_flush_log_at_trx_commit、以及快取池的剩餘容量觸發（1/2大小）同時控制著redo log落盤的頻率

2、Undo log

每做一次記錄的修改操作，都會伴隨著undo log的產生，修改操作所在的事物提交後，如果undo log不再被其他事物引用，就會被purge掉（正常情況下，會定期刪除那些標記為刪除並且不再被MVCC或rollback需要的undo頁）。

注：insert操作的undo可以在所在事物提交後立即刪除。相反，update和delete則仍然需要在一段時間內儲存undo

3、binlog

sync_binlog，innodb_flush_log_at_trx_commit 控制著事物提交是如何影響binlog落盤的。

而innodb_support_xa同時限制著redo log和binlog。

4、Data

BP中髒頁的重新整理，在關閉時，由innodb_fast_shutdown控制。

innodb_fast_shutdown決定了InnoDB在關閉時需要做那些事情，可選取值：0、1、2

0、對所有undo頁進行purge（資料庫重啟意味著所有的undo頁都變為無用的了），對change buffer進行merge，重新整理BP中的髒頁。稱之為“slow shutdown”或者“clean shutdown”，可能會耗費幾分鐘，甚至幾小時。在進行MySQL大版本升降級時，需要如此設定。

1、預設值。在=0的操作的基礎上，跳過那些一定要flush的操作（certain flush operations）僅重新整理髒頁，稱之為“fast shutdown”。

2、不重新整理BP中的髒頁到磁碟上，僅重新整理redo log buffer之後就直接shutdown，就好似MySQL是crash掉的。（下次重啟時將會耗時在crash recovery的過程中）。一般用於緊急情況下，需要儘快關機的情況。

由於模式0在資料庫重啟時，不需要做crash recovery，所以啟動速度是最快的；而模式1需要做少量的crash recovery，速度適中；反觀模式2，則要耗費大量的時間在這個過程上。

總結如下：

innodb_force_recovery決定了InnoDB在開啟時需要做那些事情，可選取值：0~6。預設0

參考文件：