MySQL Undo Log和Redo Log介紹

chenfeng發表於2018-05-02
Undo Log
Undo Log 是為了實現事務的原子性,在MySQL資料庫InnoDB儲存引擎中,還用Undo Log來實現多版本併發控制(簡稱:MVCC)。


- 事務的原子性(Atomicity)
  事務中的所有操作,要麼全部完成,要麼不做任何操作,不能只做部分操作。如果在執行的過程中發生
  了錯誤,要回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過。


- 原理
  Undo Log的原理很簡單,為了滿足事務的原子性,在操作任何資料之前,首先將資料備份到一個地方
  (這個儲存資料備份的地方稱為Undo Log)。然後進行資料的修改。如果出現了錯誤或者使用者執行了
  ROLLBACK語句,系統可以利用Undo Log中的備份將資料恢復到事務開始之前的狀態。


除了可以保證事務的原子性,Undo Log也可以用來輔助完成事務的持久化。


- 事務的永續性(Durability)
  事務一旦完成,該事務對資料庫所做的所有修改都會持久的儲存到資料庫中。為了保證永續性,資料庫
  系統會將修改後的資料完全的記錄到持久的儲存上。


- 用Undo Log實現原子性和持久化的事務的簡化過程
  假設有A、B兩個資料,值分別為1,2。
  A.事務開始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄B=2到undo log.
  E.修改B=4.
  F.將undo log寫到磁碟。
  G.將資料寫到磁碟。
  H.事務提交
  這裡有一個隱含的前提條件:‘資料都是先讀到記憶體中,然後修改記憶體中的資料,最後將資料寫回磁碟’。


  之所以能同時保證原子性和持久化,是因為以下特點:
  A. 更新資料前記錄Undo log。
  B. 為了保證永續性,必須將資料在事務提交前寫到磁碟。只要事務成功提交,資料必然已經持久化。
  C. Undo log必須先於資料持久化到磁碟。如果在G,H之間系統崩潰,undo log是完整的,
     可以用來回滾事務。
  D. 如果在A-F之間系統崩潰,因為資料沒有持久化到磁碟。所以磁碟上的資料還是保持在事務開始前的狀態。


缺陷:每個事務提交前將資料和Undo Log寫入磁碟,這樣會導致大量的磁碟IO,因此效能很低。


如果能夠將資料快取一段時間,就能減少IO提高效能。但是這樣就會喪失事務的永續性。因此引入了另外一
種機制來實現持久化,即Redo Log.


Redo Log

- 原理
  和Undo Log相反,Redo Log記錄的是新資料的備份。在事務提交前,只要將Redo Log持久化即可,
  不需要將資料持久化。當系統崩潰時,雖然資料沒有持久化,但是Redo Log已經持久化。系統可以根據
  Redo Log的內容,將所有資料恢復到最新的狀態。


- Undo + Redo事務的簡化過程
  假設有A、B兩個資料,值分別為1,2.
  A.事務開始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄A=3到redo log.
  E.記錄B=2到undo log.
  F.修改B=4.
  G.記錄B=4到redo log.
  H.將redo log寫入磁碟。
  I.事務提交


- Undo + Redo事務的特點
  A. 為了保證永續性,必須在事務提交前將Redo Log持久化。
  B. 資料不需要在事務提交前寫入磁碟,而是快取在記憶體中。
  C. Redo Log 保證事務的永續性。
  D. Undo Log 保證事務的原子性。
  E. 有一個隱含的特點,資料必須要晚於redo log寫入持久儲存。


- IO效能
  Undo + Redo的設計主要考慮的是提升IO效能。雖說透過快取資料,減少了寫資料的IO.
  但是卻引入了新的IO,即寫Redo Log的IO。如果Redo Log的IO效能不好,就不能起到提高效能的目的。
  為了保證Redo Log能夠有比較好的IO效能,InnoDB 的 Redo Log的設計有以下幾個特點:


  A. 儘量保持Redo Log儲存在一段連續的空間上。因此在系統第一次啟動時就會將日誌檔案的空間完全分配。
     以順序追加的方式記錄Redo Log,透過順序IO來改善效能。
  B. 批次寫入日誌。日誌並不是直接寫入檔案,而是先寫入redo log buffer.當需要將日誌重新整理到磁碟時
     (如事務提交),將許多日誌一起寫入磁碟.
  C. 併發的事務共享Redo Log的儲存空間,它們的Redo Log按語句的執行順序,依次交替的記錄在一起,
     以減少日誌佔用的空間。例如,Redo Log中的記錄內容可能是這樣的:
     記錄1: <trx1, insert …>
     記錄2: <trx2, update …>
     記錄3: <trx1, delete …>
     記錄4: <trx3, update …>
     記錄5: <trx2, insert …>
  D. 因為C的原因,當一個事務將Redo Log寫入磁碟時,也會將其他未提交的事務的日誌寫入磁碟。
  E. Redo Log上只進行順序追加的操作,當一個事務需要回滾時,它的Redo Log記錄也不會從
     Redo Log中刪除掉。


02 – 恢復(Recovery)


- 恢復策略
  前面說到未提交的事務和回滾了的事務也會記錄Redo Log,因此在進行恢復時,這些事務要進行特殊的
  的處理.有2中不同的恢復策略:


  A. 進行恢復時,只重做已經提交了的事務。
  B. 進行恢復時,重做所有事務包括未提交的事務和回滾了的事務。然後透過Undo Log回滾那些
     未提交的事務。


- InnoDB儲存引擎的恢復機制
  MySQL資料庫InnoDB儲存引擎使用了B策略, InnoDB儲存引擎中的恢復機制有幾個特點:


  A. 在重做Redo Log時,並不關心事務性。 恢復時,沒有BEGIN,也沒有COMMIT,ROLLBACK的行為。
     也不關心每個日誌是哪個事務的。儘管事務ID等事務相關的內容會記入Redo Log,這些內容只是被當作
     要操作的資料的一部分。
  B. 使用B策略就必須要將Undo Log持久化,而且必須要在寫Redo Log之前將對應的Undo Log寫入磁碟。
     Undo和Redo Log的這種關聯,使得持久化變得複雜起來。為了降低複雜度,InnoDB將Undo Log看作
     資料,因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以象資料一樣快取起來,
     而不用在redo log之前寫入磁碟了。
     包含Undo Log操作的Redo Log,看起來是這樣的:
     記錄1: <trx1, Undo log insert <undo_insert …>>
     記錄2: <trx1, insert …>
     記錄3: <trx2, Undo log insert <undo_update …>>
     記錄4: <trx2, update …>
     記錄5: <trx3, Undo log insert <undo_delete …>>
     記錄6: <trx3, delete …>
  C. 到這裡,還有一個問題沒有弄清楚。既然Redo沒有事務性,那豈不是會重新執行被回滾了的事務?
     確實是這樣。同時Innodb也會將事務回滾時的操作也記錄到redo log中。回滾操作本質上也是
     對資料進行修改,因此回滾時對資料的操作也會記錄到Redo Log中。
     一個回滾了的事務的Redo Log,看起來是這樣的:
     記錄1: <trx1, Undo log insert <undo_insert …>>
     記錄2: <trx1, insert A…>
     記錄3: <trx1, Undo log insert <undo_update …>>
     記錄4: <trx1, update B…>
     記錄5: <trx1, Undo log insert <undo_delete …>>
     記錄6: <trx1, delete C…>
     記錄7: <trx1, insert C>
     記錄8: <trx1, update B to old value>
     記錄9: <trx1, delete A>
     一個被回滾了的事務在恢復時的操作就是先redo再undo,因此不會破壞資料的一致性.


- InnoDB儲存引擎中相關的函式
  Redo: recv_recovery_from_checkpoint_start()
  Undo: recv_recovery_rollback_active()
  Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15498/viewspace-2153665/,如需轉載,請註明出處,否則將追究法律責任。

相關文章