數據庫存放數據的文件，本文稱其爲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