Undo log日誌回放

引言：乙個看起來正確的過程

1. 宕機時刻尚未提交的事務對資料的修改需要回滾

實現整理的過程稱之為「日誌回放」。通過從後向前回放undo log日誌，直到找到commit點為止，這樣就保證了資料一致性。

上面的過程看起來很完美。真的完美嗎？問題出在這裡：如果系統中同時有多個事務在執行，undo log中的commit點該如何定義呢？可能存在多個等待commit的點。

（繼續之前考慮一下global serializability，多個commit點與此衝突嗎？）

實戰：可以工作的過程

方法1：系統重啟回放日誌，只需要從後往前掃瞄日誌檔案，對於所有沒有commit的事務按照日誌記錄中的資料做回滾操作。

這個方法肯定是可以工作的，其問題在於要求掃瞄所有commit日誌，代價不菲。

方法2：使用checkpoint，拉起乙個大柵欄。

checkpoint可以看做是對引言中「commit點「的展開，它好比乙個較寬的柵欄（fence），將所有已經開始、尚未commit的事務都記錄下來，等待這些事務完成之後再在日誌中寫入一條「在這個柵欄架起來之前的那些狀態一致了」的標記。為什麼是「架起來之前的」呢？因為在架起柵欄後有一段等待事務完成時間，這段時間裡會有新的事務發起，他們也會繼續寫日誌，對於這些事務checkpoint不關注。

生成checkpoint的過程：

1. 在日誌中寫下create_ckpt(t1,t2,..,tn)，其中ti表示寫入create_ckpt之前尚未完成的事務

2. 等待t1~tn這些事務完成。在等待過程中可能會有新的事務寫日誌。

3. 在日誌中寫入end_ckpt

日誌回放過程：

1. 從後往前掃瞄日誌，如果先遇到end_ckpt，那麼說明create_ckpt中記錄的t1~tn這些事務都已經完成，將日誌回放至create_ckpt處即可。之前的日誌均可以丟棄。如果先遇到create_ckpt，那麼說明t1~tn這些事務可能還有沒完成的，那麼為了保證global serialization，將日誌回滾到t1~tn中最早出現的那一條之前即可。例如t3是t1~tn中最先開始的事務，則將事務回滾檢查做到t3之前即可，因為t3前的所有資料均已經確保commit了。

剩餘問題：

如何保證事務的global serializability？

參考文獻：無施的

Undo log日誌回放

Undo log日誌回放

Undo log日誌回放

如何解決loadrunner回放日誌中的亂碼問題

相關推薦