當事務(Transaction)需要修改某條記錄（row）時，InnoDB需要將該數據所在的page從disk讀到bufferpool中，事務提交后，InnoDB修改page中的記錄(row)。這時bufferpool中的page就已經和disk中的不一樣了，我們稱bufferpool中的page為dirtypage。Dirtypage等待flush到disk上。

dirtypage既然是在Bufferpool中，那么如果系統突然斷電Dirtypage中的數據修改是否會丟失？這個擔心是很有必要的，例如如果一個用戶完成一個操作（數據庫完成了一個事務，page已經在bufferpool中修改，但dirtypage尚未flush），這時系統斷電，bufferpool數據全部消失。那么，這個用戶完成的操作（導致的數據庫修改）是否會丟失呢？答案是不會(innodb_flush_log_at_trx_commit=1)。這就是redolog要做的事情，在disk上記錄更新。

redolog在每次事務commit的時候，就立刻將事務更改操作記錄到redolog。所以即使bufferpool中的dirtypage在斷電時丟失，InnoDB在啟動時，仍然會根據redolog中的記錄完成數據恢復。

redolog的另一個作用是，通過延遲dirtypage的flush最小化磁盤的randomwrites。（redolog會合并一段時間內TRX對某個page的修改）

正常情況下，dirtypage什么時候flush到disk上？
1).redolog是一個環(ring)結構，當redo空間占滿時，將會將部分dirtypageflush到disk上，然后釋放部分redolog。這種情況可以通過Innodb_log_wait(SHOWGLOBALSTATUS)觀察，情況發生該計數器會自增一次。
2).當需要在Bufferpool分配一個page，但是已經滿了，并且所有的page都是dirty的（否則可以釋放不dirty的page），通常是不會發生的。這時候必須flushdirtypagestodisk。這種情況將會記錄到Innodb_buffer_pool_wait_free中。一般地，可以可以通過啟動參數innodb_max_dirty_pages_pct控制這種情況，當bufferpool中的dirtypage到達這個比例的時候，將會強制設定一個checkpoint，并把dirtypageflush到disk中。
3).檢測到系統空閑的時候，會flush，每次64pages。

涉及的InnoDB配置參數：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；狀態參數：Innodb_log_wait、Innodb_buffer_pool_wait_free。