針對持久記憶體的後寫日誌

後寫日誌

Write behind logging

基本思想

NVM 的優點是可位元組定址、接近記憶體的高效能、順序訪問和隨機訪問差距不大。 2016 年 VLDB 會議上《 write behind logging 》論文專門針對 NVM 設計了一種新的日誌記錄及恢復協議。主要思想是去掉了傳統的 append only 的 redo 和 undo 日誌，但仍然需要保留 undo 資訊用來回滾未提交事務。事務提交前需要將該事務的所有修改強制刷盤，之後在 log 中記錄 commit 標記，即這裡所說的 WBL 。恢復過程中，通過分析 commit 標記將未提交的事務通過 undo 資訊回滾掉。

而這篇論文在這個思想基礎上又進行了一系列優化，下面介紹其機制。首先吐槽一下，這篇論文寫得不是很清晰，理解起來比較困難。下面是深入理解後的機制，有不當地方還望指正。

機制

1、 幾個概念

DTT 表中元組結構 ：事務ID+ 表 ID+ 更改位置

資料頁中的元組結構 ：

tuple id+trx id+begin commit 時間戳 + end commit 時間戳 + 上個版本號的 tuple ID +data

Cp ：該時間戳之後的提交的事務其資料不保證已經持久化到磁碟

2、一個事務操作過程

Begin;

執行操作，修改DRAM 中的資料頁

新增一個元祖到DTT 表中，該元祖不包括插入後的值

Commit ：

1 ）記錄下各個該事務的提交時間戳 t1

2 ）掃描 DTT 表得到該事務相關元組

3 ）計算 cp 和 cd 值

4 ）將 DTT 表中元組持久化到磁碟，此時元組中加上了提交時間戳 t1

5 ）將 cp 和 cd 構成的 WBL 持久化到 NVM

6 ）通知完成組提交，釋放 DTT

Rollback ：

    1 ）通過 DTT 中資訊進行回滾。

3、一個事務操作過程圖示

 

若在trx6 commit 的時間點，系統故障，那麼重啟時從 WBL 日誌檔案中遍歷得到最後一個 WBL 即 {4 ，（ 5,100 ） } ，得到活躍的事務為 4 ，大於 5 的事務都未提交。分析到這裡恢復就完成，即可接受新事務。

但是磁碟上的髒資料怎麼處理？會啟用一個單獨的回收執行緒，掃描表中記錄，若記錄的時間戳大於5 ，比如事務 6 的記錄，他是不可見的，即將它回收掉；對於 1,3,2,5 都是可見的，不做處理，對於 4 ，他在組提交未提交的事務連結串列裡，也將它回收掉。

4、缺點及疑惑

1 ）文中沒有詳細說明記錄是如何回收的，是後續事務訪問到進行判斷處理，還是說只是另外回收執行緒全部掃描進行判斷。資料量如果特別大的話，掃描的代價豈不是很大？全部掃描完後，才將不用的 WBL 回收掉？

2 ）如果在高可用場景下，無法滿足要求，仍然需要相應的 WAL 進行復制

3 ）後續的可見性判斷比較複雜，文中沒有詳細說明

原文及參考

http://www.vldb.org/pvldb/vol10/p337-arulraj.pdf

http://mysql.taobao.org/monthly/2019/01/01/

https://github.com/cmu-db/peloton/wiki/Write-Ahead-Logging