理解資料庫中的undo日誌、redo日誌、檢查點

資料庫存放數據的文件，本文稱其為data file。
資料庫的內容在記憶體里是有緩存的，這裡命名為db buffer。某次操作，我們取了資料庫某表格中的數據，這個數據會在記憶體中緩存一些時間。對這個數據的修改在開始時候也只是修改在記憶體中的內容。當db buffer已滿或者遇到其他的情況，這些數據會寫入data file。

undo，redo

日誌在記憶體里也是有緩存的，這裡將其叫做log buffer。磁碟上的日誌文件稱為log file。log file一般是追加內容，可以認為是順序寫，順序寫的磁碟IO開銷要小於隨機寫。

Undo日誌記錄某數據被修改前的值，可以用來在事務失敗時進行rollback；Redo日誌記錄某數據塊被修改後的值，可以用來恢復未寫入data file的已成功事務更新的數據。下麵的示例來自於楊傳輝《大數據分散式存儲系統 原理解析與架構實踐》，略作改動。

例如某一事務的事務序號為T1，其對數據X進行修改，設X的原值是5，修改後的值為15，那麼Undo日誌為<T1, X, 5>，Redo日誌為<T1, X, 15>。

也有把undo和redo結合起來的做法，叫做Undo/Redo日誌，在這個例子中Undo/Redo日誌為<T1, X, 5, 15>。

當用戶生成一個資料庫事務時，undo log buffer會記錄被修改的數據的原始值，redo會記錄被修改的數據的更新後的值。

redo日誌應首先持久化在磁碟上，然後事務的操作結果才寫入db buffer，（此時，記憶體中的數據和data file對應的數據不同，我們認為記憶體中的數據是臟數據），db buffer再選擇合適的時機將數據持久化到data file中。這種順序可以保證在需要故障恢復時恢復最後的修改操作。先持久化日誌的策略叫做Write Ahead Log，即預寫日誌。

在很多系統中，undo日誌並非存到日誌文件中，而是存放在資料庫內部的一個特殊段中。本文中就把這些存儲行為都泛化為undo日誌存儲到undo log file中。

對於某事務T，在log file的記錄中必須開始於事務開始標記（比如“start T”），結束於事務結束標記（比如“end T”、”commit T”）。在系統恢復時，如果在log file中某個事務沒有事務結束標記，那麼需要對這個事務進行undo操作，如果有事務結束標記，則redo。

在db buffer中的內容寫入磁碟資料庫文件之前，應當把log buffer的內容寫入磁碟日誌文件。

有一個問題，redo log buffer和undo log buffer存儲的事務數量是多少，是按照什麼規則將日誌寫入log file？如果存儲的事務數量都是1個，也就意味著是將日誌立即刷入磁碟，那麼數據的一致性很好保證。在執行事T時，突然斷電，如果未對磁碟上的redo log file發生追加操作，可以把這個事務T看做未成功。如果redo log file被修改，則認為事務是成功了，重啟資料庫使用redo log恢複數據到db buffer和 data file即可。

如果存儲多個的話，其實也挺好解釋的。就是db buffer寫入data file之前，先把日誌寫入log file。這種方式可以減少磁碟IO，增加吞吐量。不過，這種方式適用於一致性要求不高的場合。因為如果出現斷電等系統故障，log buffer、db buffer中的完成的事務會丟失。以轉賬為例，如果用戶的轉賬事務在這種情況下丟失了，這意味著在系統恢復後用戶需要重新轉賬。

檢查點checkpoint

checkpoint是為了定期將db buffer的內容刷新到data file。當遇到記憶體不足、db buffer已滿等情況時，需要將db buffer中的內容/部分內容（特別是臟數據）轉儲到data file中。在轉儲時，會記錄checkpoint發生的”時刻“。在故障回覆時候，只需要redo/undo最近的一次checkpoint之後的操作。

冪等性問題

在日誌文件中的操作記錄應該具有冪等性。冪等性，就是說同一個操作執行多次和執行一次，結果是一樣的。例如，5*1 = 5*1*1*1，所以對5的乘1操作具有冪等性。日誌文件在故障恢復中，可能會回放多次（比如第一次回放到一半時系統斷電了，不得不再重新回放），如果操作記錄不滿足冪等性，會造成數據錯誤。

轉載：http://blog.csdn.net/kobejayandy/article/details/50885693

（此文章僅用於個人記憶知識所用）