?

1.1.?Log?&?Checkpoint

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

?

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

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

?

1.1.1.?寫入機制

1.1.1.1.?Log寫入

?

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

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

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

l?寫入日志：找到偏移400M的位置，寫入512字節日志內容，下一個事務的LSN就是1000000512；

?

1.1.1.2.?Checkpoint寫入

?

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

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

?

?

1.1.2.?管理機制

?

由于Checkpoint和日志緊密相關，將日志和Checkpoint一起說明，詳細的實現機制如下：

?

?

如上圖所示，Innodb的一條事務日志共經歷4個階段：

l?創建階段：事務創建一條日志；

l?日志刷盤：日志寫入到磁盤上的日志文件；

l?數據刷盤：日志對應的臟頁數據寫入到磁盤上的數據文件；

l?寫CKP：日志被當作Checkpoint寫入日志文件；

?

?

對應這4個階段，系統記錄了4個日志相關的信息，用于其它各種處理使用：

l?Log?sequence?number（LSN1）：當前系統LSN最大值，新的事務日志LSN將在此基礎上生成（LSN1+新日志的大小）；

l?Log?flushed?up?to（LSN2）：當前已經寫入日志文件的LSN；

l?Oldest?modified?data?log（LSN3）：當前最舊的臟頁數據對應的LSN，寫Checkpoint的時候直接將此LSN寫入到日志文件；

l?Last?checkpoint?at（LSN4）：當前已經寫入Checkpoint的LSN；

?

?

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

?

具體的樣例如下（使用show?innodb?status?/G命令查看，Oldest?modified?data?log沒有顯示）：

?

?

?

1.1.3.?保護機制

?

Innodb的數據并不是實時寫盤的，為了避免宕機時數據丟失，保證數據的ACID屬性，Innodb至少要保證數據對應的日志不能丟失。對于不同的情況，Innodb采取不同的對策：

l?宕機導致日志丟失
Innodb有日志刷盤機制，可以通過innodb_flush_log_at_trx_commit參數進行控制；

l?日志覆蓋導致日志丟失

Innodb日志文件大小是固定的，寫入的時候通過取余來計算偏移量，這樣存在兩個LSN寫入到同一位置的可能，后面寫的把前面寫得就覆蓋了，以“寫入機制”章節的樣例為例，LSN＝100000000和LSN＝1600000000兩個日志的偏移量是相同的了。這種情況下，為了保證數據一致性，必須要求LSN=1000000000對應的臟頁數據都已經刷到磁盤中，也就是要求Last?checkpoint對應的LSN一定要大于1000000000，否則覆蓋后日志也沒有了，數據也沒有刷盤，一旦宕機，數據就丟失了。

?

?

為了解決第二種情況導致數據丟失的問題，Innodb實現了一套日志保護機制，詳細實現如下：

?

?

上圖中，直線代表日志空間（Log?cap，約等于日志文件總大小*0.8，0.8是一個安全系數)，Ckp?age和Buf?age是兩個浮動的點，Buf?async、Buf?sync、Ckp?async、Ckp?sync是幾個固定的點。各個概念的含義如下：

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

?

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

?

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

?

?

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

?

附注：Innodb的日志保護機制實現可以參考log0log.c文件的void log_check_margins(void)函數。

轉載于:https://www.cnblogs.com/bluecoder/p/3737286.html

總結

以上是生活随笔為你收集整理的MySQL Innodb日志机制深入分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。