InnoDBRedoFlush及臟頁刷新機制深入分析

概要：

創(chuàng)新互聯(lián)2013年至今，先為烏魯木齊等服務(wù)建站，烏魯木齊等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為烏魯木齊企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

我們知道InnoDB采用Write Ahead Log策略來防止宕機數(shù)據(jù)丟失，即事務(wù)提交時，先寫重做日志，再修改內(nèi)存數(shù)據(jù)頁，這樣就產(chǎn)生了臟頁。既然有重做日志保證數(shù)據(jù)持久性，查詢時也可以直接從緩沖池頁中取數(shù)據(jù)，那為什么還要刷新臟頁到磁盤呢？如果重做日志可以無限增大，同時緩沖池足夠大，能夠緩存所有數(shù)據(jù)，那么是不需要將緩沖池中的臟頁刷新到磁盤。但是，通常會有以下幾個問題：

服務(wù)器內(nèi)存有限，緩沖池不夠用，無法緩存全部數(shù)據(jù)
重做日志無限增大成本要求太高
宕機時如果重做全部日志恢復(fù)時間過長

事實上，當(dāng)數(shù)據(jù)庫宕機時，數(shù)據(jù)庫不需要重做所有的日志，只需要執(zhí)行上次刷入點之后的日志。這個點就叫做Checkpoint，它解決了以上的問題：

縮短數(shù)據(jù)庫恢復(fù)時間
緩沖池不夠用時，將臟頁刷新到磁盤
重做日志不可用時，刷新臟頁

重做日志被設(shè)計成可循環(huán)使用，當(dāng)日志文件寫滿時，重做日志中對應(yīng)數(shù)據(jù)已經(jīng)被刷新到磁盤的那部分不再需要的日志可以被覆蓋重用。

InnoDB引擎通過LSN(Log Sequence Number)來標(biāo)記版本，LSN是日志空間中每條日志的結(jié)束點，用字節(jié)偏移量來表示。每個page有LSN，redo log也有LSN，Checkpoint也有LSN?？梢酝ㄟ^命令show engine innodb status來觀察：

---
LOG
---
Log sequence number 1039878815567
Log flushed up to 1039878815567
Pages flushed up to 1039878814486
Last checkpoint at 1039878814486
0 pending log writes, 0 pending chkp writes
5469310 log i/o's done, 1.00 log i/o's/second

Checkpoint機制每次刷新多少頁，從哪里取臟頁，什么時間觸發(fā)刷新？這些都是很復(fù)雜的。有兩種Checkpoint，分別為：

Sharp Checkpoint
Fuzzy Checkpoint

Sharp Checkpoint發(fā)生在關(guān)閉數(shù)據(jù)庫時，將所有臟頁刷回磁盤。在運行時使用Fuzzy Checkpoint進行部分臟頁的刷新。部分臟頁刷新有以下幾種：

Master Thread Checkpoint
FLUSH_LRU_LIST Checkpoint
Async/Sync Flush Checkpoint
Dirty Page too much Checkpoint

Master Thread Checkpoint

Master Thread以每秒或每十秒的速度從緩沖池的臟頁列表中刷新一定比例的頁回磁盤。這個過程是異步的，不會阻塞查詢線程。

Flush LRU List Checkpoint
InnoDB要保證LRU列表中有100左右空閑頁可使用。在InnoDB1.1.X版本前，要檢查LRU中是否有足夠的頁用于用戶查詢操作線程，如果沒有，會將LRU列表尾端的頁淘汰，如果被淘汰的頁中有臟頁，會強制執(zhí)行Checkpoint刷回臟頁數(shù)據(jù)到磁盤，顯然這會阻塞用戶查詢線程。從InnoDB1.2.X版本開始，這個檢查放到單獨的Page Cleaner Thread中進行，并且用戶可以通過innodb_lru_scan_depth控制LRU列表中可用頁的數(shù)量，默認(rèn)值為1024。

Async/Sync Flush Checkpoint
是指重做日志文件不可用時，需要強制將臟頁列表中的一些頁刷新回磁盤。這可以保證重做日志文件可循環(huán)使用。在InnoDB1.2.X版本之前，Async Flush Checkpoint會阻塞發(fā)現(xiàn)問題的用戶查詢線程，Sync Flush Checkpoint會阻塞所有查詢線程。InnoDB1.2.X之后放到單獨的Page Cleaner Thread。

Dirty Page Too Much Checkpoint
臟頁數(shù)量太多時，InnoDB引擎會強制進行Checkpoint。目的還是為了保證緩沖池中有足夠可用的空閑頁。其可以通過參數(shù)innodb_max_dirty_pages_pct來設(shè)置，默認(rèn)為75%。

(root@localhost)[(none)]> show variables like 'innodb_max_dirty_pages_pct';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| innodb_max_dirty_pages_pct | 75 |
+----------------------------+-------+
1 row in set (0.00 sec

以上是臟頁刷新的幾種觸發(fā)機制，接下來，細說一下日志機制及其中第3點Async/Sync flush checkpoint原理。

Log及Checkpoint簡介

Innodb的事務(wù)日志是指Redo log，簡稱Log,保存在日志文件ib_logfile*里面。Innodb還有另外一個日志Undo log，但Undo log是存放在共享表空間里面的（ibdata*文件）。

由于Log和Checkpoint緊密相關(guān)，因此將這兩部分合在一起分析。

名詞解釋：LSN，日志序列號，Innodb的日志序列號是一個64位的整型。

Log寫入

LSN實際上對應(yīng)日志文件的偏移量，新的LSN＝舊的LSN + 寫入的日志大小。舉例如下：

LSN＝1G，日志文件大小總共為600M，本次寫入512字節(jié)，則實際寫入操作為：

| --- 求出偏移量：由于LSN數(shù)值遠大于日志文件大小，因此通過取余方式，得到偏移量為400M；

| --- 寫入日志：找到偏移400M的位置，寫入512字節(jié)日志內(nèi)容，下一個事務(wù)的LSN就是1000000512；

Checkpoint寫入

Innodb實現(xiàn)了Fuzzy Checkpoint的機制，每次取到最老的臟頁，然后確保此臟頁對應(yīng)的LSN之前的LSN都已經(jīng)寫入日志文件，再將此臟頁的LSN作為Checkpoint點記錄到日志文件，意思就是“此LSN之前的LSN對應(yīng)的日志和數(shù)據(jù)都已經(jīng)寫入磁盤文件”。恢復(fù)數(shù)據(jù)文件的時候，Innodb掃描日志文件，當(dāng)發(fā)現(xiàn)LSN小于Checkpoint對應(yīng)的LSN，就認(rèn)為恢復(fù)已經(jīng)完成。

Checkpoint寫入的位置在日志文件開頭固定的偏移量處，即每次寫Checkpoint都覆蓋之前的Checkpoint信息。

Flush刷新流程及原理介紹

由于Checkpoint和日志緊密相關(guān)，將日志和Checkpoint一起說明，詳細的實現(xiàn)機制如下：

如上圖所示，Innodb的一條事務(wù)日志共經(jīng)歷4個階段：

1）創(chuàng)建階段：事務(wù)創(chuàng)建一條日志；

2）日志刷盤：日志寫入到磁盤上的日志文件；

3）數(shù)據(jù)刷盤：日志對應(yīng)的臟頁數(shù)據(jù)寫入到磁盤上的數(shù)據(jù)文件；

4）寫CKP：日志被當(dāng)作Checkpoint寫入日志文件；

對應(yīng)這4個階段，系統(tǒng)記錄了4個日志相關(guān)的信息，用于其它各種處理使用：

Log sequence number（LSN1）：當(dāng)前系統(tǒng)LSN最大值，新的事務(wù)日志LSN將在此基礎(chǔ)上生成（LSN1+新日志的大小）；

Log flushed up to（LSN2）：當(dāng)前已經(jīng)寫入日志文件的LSN；

Pages flushed up to（LSN3）：當(dāng)前最舊的臟頁數(shù)據(jù)對應(yīng)的LSN，寫Checkpoint的時候直接將此LSN寫入到日志文件；

Last checkpoint at（LSN4）：當(dāng)前已經(jīng)寫入Checkpoint的LSN；

對于系統(tǒng)來說，以上4個LSN是遞減的，即： LSN1>=LSN2>=LSN3>=LSN4.

具體的樣例如下（使用show engine innodb status \G命令查看）

概念計算含義 Ckp age LSN1- LSN4 還沒有做Checkpoint的日志范圍，若Ckp age超過日志空間，說明被覆蓋的日志（LSN1－LSN4－Log cap）對應(yīng)日志和數(shù)據(jù)“可能”還沒有刷到磁盤上 Buf age LSN1- LSN3 還沒有將臟頁刷盤的日志的范圍，若Buf age超過日志空間，說明被覆蓋的日志（LSN1－LSN3－Log cap）對應(yīng)數(shù)據(jù)“肯定”還沒有刷到磁盤上 Buf async 日志空間大小 * 7/8 強制將Buf age-Buf async的臟頁刷盤，此時事務(wù)還可以繼續(xù)執(zhí)行，所以為async，對事務(wù)的執(zhí)行速度沒有直接影響（有間接影響，例如CPU和磁盤更忙了，事務(wù)的執(zhí)行速度可能受到影響） Buf sync 日志空間大小 * 15/16 強制將2*(Buf age-Buf async)的臟頁刷盤，此時事務(wù)停止執(zhí)行，所以為sync，由于有大量的臟頁刷盤，因此阻塞的時間比Ckp sync要長。 Ckp async 日志空間大小 * 31/32 強制寫Checkpoint，此時事務(wù)還可以繼續(xù)執(zhí)行，所以為async，對事務(wù)的執(zhí)行速度沒有影響（間接影響也不大，因為寫Checkpoint的操作比較簡單） Ckp sync 日志空間大小 * 64/64 強制寫Checkpoint，此時事務(wù)停止執(zhí)行，所以為sync，但由于寫Checkpoint的操作比較簡單，即使阻塞，時間也很短

當(dāng)事務(wù)執(zhí)行速度大于臟頁刷盤速度時，Ckp age和Buf age會逐步增長，當(dāng)達到async點的時候，強制進行臟頁刷盤或者寫Checkpoint，如果這樣做還是趕不上事務(wù)執(zhí)行的速度，則為了避免數(shù)據(jù)丟失，到達sync點的時候，會阻塞其它所有的事務(wù)，專門進行臟頁刷盤或者寫Checkpoint。

因此從理論上來說,只要事務(wù)執(zhí)行速度大于臟頁刷盤速度，最終都會觸發(fā)日志保護機制，進而將事務(wù)阻塞，導(dǎo)致MySQL操作掛起。

由于寫Checkpoint本身的操作相比寫臟頁要簡單，耗費時間也要少得多，且Ckp sync點在Buf sync點之后，因此絕大部分的阻塞都是阻塞在了Buf sync點，這也是當(dāng)事務(wù)阻塞的時候，IO很高的原因，因為這個時候在不斷的刷臟頁數(shù)據(jù)到磁盤。例如如下截圖的日志顯示了很多事務(wù)阻塞在了Buf sync點：

標(biāo)題名稱：InnoDBRedoFlush及臟頁刷新機制深入分析
分享地址：http://weahome.cn/article/gcjsge.html