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

season0891發表於2008-11-03
當你使用UPDATE, INSERT, DELETE語句更新資料的時候,你就改變了兩個地方的資料:log bufferdata buffersBuffers是固定長度的記憶體塊,通常是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。在這個例子中#5Log Sequence NumberLSN),它對於接下來操作的時序安排是至關重要的。
 
下面是data-change的一些細節:
1.         一個INSERT log記錄僅包含一個新資料,它對於在頁上重做操作是足夠的了,因此被稱為一個redo條目。
2.         LSN不是log記錄的一個域,它是檔案中的一個絕對地址的相對偏移值。
InnoDB改變了log bufferdata buffer之後,接下來就是寫盤了。這就是複雜的地方。有多個執行緒在監控buffer的活動情況,有三種情況――overflow checkpointcommit――可以導致寫盤操作。
 
Overflows情況下發生了什麼?
Overflow是很少發生的情況,因為InnoDB採用pro-active措施來防止buffers被填滿。但是我們還是來看看下面兩種情況:
1.         如果log buffer滿了,InnoDBInnoDBbuffer的末尾寫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只保證:(alogdata buffers不會超過某個限制點;(blog始終比data先寫盤;(c)沒有哪個data buffer的頁頭LSN等於被覆蓋寫的log記錄。也就是說InnoDB”Fuzzy Checkpoint”
COMMIT的時候,InnoDB不會將dirty data page寫盤。之所以強調這個是因為,很容易讓人想到,提交改變就是將所有東西寫到一個持久媒介上。其實,只有log記錄需要寫。寫dirty data page只可能發生在overflowcheckpoint時刻,因為它們的內容是多餘的。
 
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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章