Undo Log

數據庫事務開始之前，會將要修改的記錄存放到 Undo 日志里，當事務回滾時或者數據庫崩潰時，可以利用 Undo 日志，撤銷未提交事務對數據庫產生的影響。

Undo Log產生和銷毀

Undo Log在事務開始前產生；事務在提交時，并不會立刻刪除undo log，innodb會將該事務對應的undo log放入到刪除列表中，后面會通過后臺線程purge thread進行回收處理。
Undo Log屬于邏輯日志，記錄一個變化過程。例如執行一個delete，undolog會記錄一個insert；執行一個update，undolog會記錄一個相反的update。

Undo Log存儲

Undo log采用段的方式管理和記錄。在innodb數據文件中包含一種rollback segment回滾段，內部包含1024個undo log segment。可以通過下面一組參數來控制Undo log存儲。

show variables like '%innodb_undo%'; 

Undo Log作用

實現事務的原子性

Undo Log 是為了實現事務的原子性而出現的產物。事務處理過程中，如果出現了錯誤或者用戶執行了 ROLLBACK 語句，MySQL 可以利用 Undo Log 中的備份將數據恢復到事務開始之前的狀態。

實現多版本并發控制（MVCC）

Undo Log 在 MySQL InnoDB 存儲引擎中用來實現多版本并發控制。事務未提交之前，Undo Log保存了未提交之前的版本數據，Undo Log 中的數據可作為數據舊版本快照供其他并發事務進行快照讀。

事務A手動開啟事務，執行更新操作，首先會把更新命中的數據備份到 Undo Buffer中。
事務B手動開啟事務，執行查詢操作，會讀取 Undo 日志數據返回，進行快照讀

Redo Log

指事務中修改的任何數據，將最新的數據備份存儲的位置（Redo Log），被稱為重做日志。

Redo Log 的生成和釋放

隨著事務操作的執行，就會生成Redo Log，在事務提交時會將產生Redo Log寫入Log Buffer，并不是隨著事務的提交就立刻寫入磁盤文件。
等事務操作的臟頁寫入到磁盤之后，Redo Log 的使命也就完成了，Redo Log占用的空間就可以重用（被覆蓋寫入）。

Redo Log 工作原理

Redo Log 是為了實現事務的持久性而出現的產物。防止在發生故障的時間點，尚有臟頁未寫入表的 ibd 文件中，在重啟 MySQL 服務的時候，根據 Redo Log 進行重做，從而達到事務的未入磁盤數據進行持久化這一特性。

Redo Log 寫入機制

Redo Log 文件內容是以順序循環的方式寫入文件，寫滿時則回溯到第一個文件，進行覆蓋寫

write pos 是當前記錄的位置，一邊寫一邊后移，寫到最后一個文件末尾后就回到 0 號文件開頭；
checkpoint 是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數據文件；
write pos 和 checkpoint 之間還空著的部分，可以用來記錄新的操作。如果 write pos 追上checkpoint，表示寫滿，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint 推進一下。

Redo Log相關配置參數

每個InnoDB存儲引擎至少有1個重做日志文件組（group），每個文件組至少有2個重做日志文件，默認為ib_logfile0和ib_logfile1。可以通過下面一組參數控制Redo Log存儲

show variables like '%innodb_log%';

Redo Buffer 持久化到 Redo Log 的策略，可通過 Innodb_flush_log_at_trx_commit 設置

0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丟失一秒內的事務數據。由后臺Master線程每隔 1秒執行一次操作。
1（默認值）：每次事務提交執行 Redo Buffer -> OS cache -> flush cache to disk，最安全，性能最差的方式。
2：每次事務提交執行 Redo Buffer -> OS cache，然后由后臺Master線程再每隔1秒執行OS cache -> flush cache to disk 的操作。

一般建議選擇取值2，因為 MySQL 掛了數據沒有損失，整個服務器掛了才會損失1秒的事務提交數據。

以上就是MySQL 撤銷日志與重做日志(Undo Log與Redo Log)相關總結的詳細內容，更多關于MySQL 撤銷日志與重做日志(Undo Log與Redo Log)的資料請關注腳本之家其它相關文章！