解讀MySQL的InnoDB引擎日誌工作原理

season0891發表於2008-11-03
MySql
當你使用UPDATE, INSERT, DELETE語句更新資料的時候，你就改變了兩個地方的資料：log buffer和data buffers。Buffers是固定長度的記憶體塊，通常是512位元組。
LOG BUFFER           DATA BUFFER
=================    ===============
= Log Record #1 =    = Page Header =
= Log Record #2 =    = Data Row    =
= Log Record #3 =    = Data Row    =
= Log Record #4 =    = Data Row    =
=================    ===============
例如：INSERT INTO JOBS VALUES(1,2,3)語句執行之後，log buffer將增加一個新的log記錄，稱為Log Record #5，它包含一個rowid和新記錄的內容。同時，data buffer也將增加一個新行，但是，它會同時在頁頭標識：該頁最新的log記錄是Log Record #5。在這個例子中#5是Log Sequence Number（LSN），它對於接下來操作的時序安排是至關重要的。
 
下面是data-change的一些細節：
1.         一個INSERT log記錄僅包含一個新資料，它對於在頁上重做操作是足夠的了，因此被稱為一個redo條目。
2.         LSN不是log記錄的一個域，它是檔案中的一個絕對地址的相對偏移值。
在InnoDB改變了log buffer和data buffer之後，接下來就是寫盤了。這就是複雜的地方。有多個執行緒在監控buffer的活動情況，有三種情況――overflow， checkpoint和commit――可以導致寫盤操作。
 
Overflows情況下發生了什麼？
Overflow是很少發生的情況，因為InnoDB採用pro-active措施來防止buffers被填滿。但是我們還是來看看下面兩種情況：
1.         如果log buffer滿了，InnoDBInnoDB在buffer的末尾寫log。那麼情況向下面的圖一樣（log buffer只有四條記錄的空間，現在插入第五條記錄）：
LOG FILE(S) BEFORE WRITING LOG RECORD #5
=================
= Log Record #1 =
= Log Record #2 =
= Log Record #3 =
= Log Record #4 =
=================

LOG FILE(S) AFTER WRITING LOG RECORD #5
=================
= Log Record #5 =
= Log Record #2 =
= Log Record #3 =
= Log Record #4 =
=================
logs不可能永遠增長。即使InnoDB使用了某些壓縮演算法，log檔案還是會由於太大而不能放到任何磁碟驅動器上。因此InnoDB採取迴圈寫的辦法，也就是說將會覆蓋前面就的log記錄。
2.         如果data buffer滿了，InnoDB將最近使用的buffer寫入到資料庫中，但是不可能足夠的快。這種情況下，頁頭的LSN就起作用了。第一，InnoDB檢查它的LSN是否比log檔案中最近的log記錄的LSN大，只有當log趕上了data的時候，才會將資料寫到磁碟。換句話說，資料頁不會寫盤，直到相應的log記錄需要寫盤的時候。這就是先寫日誌策略。
 
CheckPoints的時候發生了什麼？
前面說過InnoDB採取了一些pro-active措施來保證不發生overflows，其中最重要的措施就是checkpointing。有一個分離的執行緒，或者說從一組修改buffers的執行緒中分離出來的一個執行緒。在特定的時間間隔，checkpointer將醒來，檢查buffer的改變，並保證寫盤操作已經發生了。
大部分DBMS在這個時候，將會把所有的buffer寫盤，這樣可以保證所有改變了但是沒寫盤的buffer都寫盤。就是說DBMS將透過”Sharp Checkpoint” flush所有”dirty”buffers。但是InnoDB只保證：（a）log和data buffers不會超過某個限制點；（b）log始終比data先寫盤；（c）沒有哪個data buffer的頁頭LSN等於被覆蓋寫的log記錄。也就是說InnoDB是”Fuzzy Checkpoint”。
在COMMIT的時候，InnoDB不會將dirty data page寫盤。之所以強調這個是因為，很容易讓人想到，提交改變就是將所有東西寫到一個持久媒介上。其實，只有log記錄需要寫。寫dirty data page只可能發生在overflow或checkpoint時刻，因為它們的內容是多餘的。
 
Recovery
在recovery裡面可以看到log是非常必要的：當資料庫發生異常的時候，資料是可以恢復的。
對於不是損壞磁碟驅動器的異常，恢復是自動進行的。InnoDB讀取最新的checkpoint日誌記錄，檢查dirty pages是否在異常發生前寫到磁碟上了，如果沒有，則讀取影響該頁的log記錄並應用它們。這被稱為”rolling forward”。因為有LSN，所以InnoDB只需要比較這個數字就可以進行同步。

本文出自 “越測越開心” 部落格，請務必保留此出處http://happytest.blog.違規廣告.com/324097/62848

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/90618/viewspace-483906/，如需轉載，請註明出處，否則將追究法律責任。

相關文章