mysql紀錄檔檔案之undo log和redo log

2022-04-15 13:00:48

前言

在資料庫系統中，既有存放資料的檔案，也有存放紀錄檔的檔案。紀錄檔在記憶體中也是有快取Log buffer，也有磁碟檔案log file，本文主要描述存放紀錄檔的檔案。

MySQL中的紀錄檔檔案，有這麼兩類常常討論到：undo紀錄檔與redo紀錄檔。

1 undo

1.1 undo是什麼

undo紀錄檔用於存放資料修改被修改前的值，假設修改 tba 表中 id=2的行資料，把Name='B' 修改為Name = 'B2' ，那麼undo紀錄檔就會用來存放Name='B'的記錄，如果這個修改出現異常，可以使用undo紀錄檔來實現回滾操作，保證事務的一致性。

對資料的變更操作，主要來自 INSERT UPDATE DELETE，而UNDO LOG中分為兩種型別，一種是 INSERT_UNDO（INSERT操作），記錄插入的唯一鍵值；一種是 UPDATE_UNDO（包含UPDATE及DELETE操作），記錄修改的唯一鍵值以及old column記錄。

Id	Name
1	A
2	B
3	C
4	D

1.2 undo引數

MySQL跟undo有關的引數設定有這些：

mysql> show global variables like '%undo%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 |
| innodb_undo_directory    | ./         |
| innodb_undo_log_truncate | OFF        |
| innodb_undo_logs         | 128        |
| innodb_undo_tablespaces  | 3          |
+--------------------------+------------+

mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128   |
| innodb_undo_log_truncate             | OFF   |
+--------------------------------------+-------+

innodb_max_undo_log_size

控制最大undo tablespace檔案的大小，當啟動了innodb_undo_log_truncate 時，undo tablespace 超過innodb_max_undo_log_size 閥值時才會去嘗試truncate。該值預設大小為1G，truncate後的大小預設為10M。

innodb_undo_tablespaces

設定undo獨立表空間個數，範圍為0-128，預設為0，0表示表示不開啟獨立undo表空間且 undo紀錄檔儲存在ibdata檔案中。該引數只能在最開始初始化MySQL範例的時候指定，如果範例已建立，這個引數是不能變動的，如果在資料庫設定文件 .cnf 中指定innodb_undo_tablespaces 的個數大於範例建立時的指定個數，則會啟動失敗，提示該引數設定有誤。

如果設定了該引數為n（n>0），那麼就會在undo目錄下建立n個undo檔案（undo001，undo002 ...... undo n），每個檔案預設大小為10M.

什麼時候需要來設定這個引數呢？

當DB寫壓力較大時，可以設定獨立UNDO表空間，把UNDO LOG從ibdata檔案中分離開來，指定 innodb_undo_directory目錄存放，可以制定到高速磁碟上，加快UNDO LOG 的讀寫效能。

innodb_undo_log_truncate

InnoDB的purge執行緒，根據innodb_undo_log_truncate設定開啟或關閉、innodb_max_undo_log_size的引數值，以及truncate的頻率來進行空間回收和 undo file 的重新初始化。

該引數生效的前提是，已設定獨立表空間且獨立表空間個數大於等於2個。

purge執行緒在truncate undo log file的過程中，需要檢查該檔案上是否還有活動事務，如果沒有，需要把該undo log file標記為不可分配，這個時候，undo log 都會記錄到其他檔案上，所以至少需要2個獨立表空間檔案，才能進行truncate 操作，標註不可分配後，會建立一個獨立的檔案undo_<space_id>_trunc.log，記錄現在正在truncate 某個undo log檔案，然後開始初始化undo log file到10M，操作結束後，刪除表示truncate動作的 undo_<space_id>_trunc.log 檔案，這個檔案保證了即使在truncate過程中發生了故障重啟資料庫服務，重啟後，服務發現這個檔案，也會繼續完成truncate操作，刪除檔案結束後，標識該undo log file可分配。

innodb_purge_rseg_truncate_frequency

用於控制purge回滾段的頻度，預設為128。假設設定為n，則說明，當Innodb Purge操作的協調執行緒 purge事務128次時，就會觸發一次History purge，檢查當前的undo log 表空間狀態是否會觸發truncate。

1.3 undo空間管理

如果需要設定獨立表空間，需要在初始化資料庫範例的時候，指定獨立表空間的數量。

UNDO內部由多個回滾段組成，即 Rollback segment，一共有128個，儲存在ibdata系統表空間中，分別從resg slot0 - resg slot127，每一個resg slot，也就是每一個回滾段，內部由1024個undo segment 組成。

回滾段（rollback segment）分配如下：

slot 0 ，預留給系統表空間；
slot 1- 32，預留給臨時表空間，每次資料庫重啟的時候，都會重建臨時表空間；
slot33-127，如果有獨立表空間，則預留給UNDO獨立表空間；如果沒有，則預留給系統表空間；

回滾段中除去32個提供給臨時表事務使用，剩下的 128-32=96個回滾段，可執行 96*1024 個並行事務操作，每個事務佔用一個 undo segment slot，注意，如果事務中有臨時表事務，還會在臨時表空間中的 undo segment slot 再佔用一個 undo segment slot，即佔用2個undo segment slot。如果錯誤紀錄檔中有：Cannot find a free slot for an undo log。則說明並行的事務太多了，需要考慮下是否要分流業務。

回滾段（rollback segment ）採用輪詢排程的方式來分配使用，如果設定了獨立表空間，那麼就不會使用系統表空間回滾段中undo segment，而是使用獨立表空間的，同時，如果回顧段正在 Truncate操作，則不分配。

2 redo

2.1 redo是什麼

當資料庫對資料做修改的時候，需要把資料頁從磁碟讀到buffer pool中，然後在buffer pool中進行修改，那麼這個時候buffer pool中的資料頁就與磁碟上的資料頁內容不一致，稱buffer pool的資料頁為dirty page 髒資料，如果這個時候發生非正常的DB服務重啟，那麼這些資料還沒在記憶體，並沒有同步到磁碟檔案中（注意，同步到磁碟檔案是個隨機IO），也就是會發生資料丟失，如果這個時候，能夠在有一個檔案，當buffer pool 中的data page變更結束後，把相應修改記錄記錄到這個檔案（注意，記錄紀錄檔是順序IO），那麼當DB服務發生crash的情況，恢復DB的時候，也可以根據這個檔案的記錄內容，重新應用到磁碟檔案，資料保持一致。

這個檔案就是redo log ，用於記錄資料修改後的記錄，順序記錄。它可以帶來這些好處：

當buffer pool中的dirty page 還沒有重新整理到磁碟的時候，發生crash，啟動服務後，可通過redo log 找到需要重新重新整理到磁碟檔案的記錄；
buffer pool中的資料直接flush到disk file，是一個隨機IO，效率較差，而把buffer pool中的資料記錄到redo log，是一個順序IO，可以提高事務提交的速度；

假設修改 tba 表中 id=2的行資料，把Name='B' 修改為Name = 'B2' ，那麼redo紀錄檔就會用來存放Name='B2'的記錄，如果這個修改在flush 到磁碟檔案時出現異常，可以使用redo log實現重做操作，保證事務的永續性。

Id	Name
1	A
2	B
3	C
4	D

這裡注意下redo log 跟binary log 的區別，redo log 是儲存引擎層產生的，而binary log是資料庫層產生的。假設一個大事務，對tba做10萬行的記錄插入，在這個過程中，一直不斷的往redo log順序記錄，而binary log不會記錄，知道這個事務提交，才會一次寫入到binary log檔案中。binary log的記錄格式有3種：row，statement跟mixed，不同格式記錄形式不一樣。

2.2 redo 引數

innodb_log_files_in_group

redo log 檔案的個數，命名方式如：ib_logfile0，iblogfile1... iblogfilen。預設2個，最大100個。

innodb_log_file_size

檔案設定大小，預設值為 48M，最大值為512G，注意最大值指的是整個 redo log系列檔案之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大於最大值512G。

innodb_log_group_home_dir

檔案存放路徑

innodb_log_buffer_size

Redo Log 快取區，預設8M，可設定1-8M。延遲事務紀錄檔寫入磁碟，把redo log 放到該緩衝區，然後根據 innodb_flush_log_at_trx_commit引數的設定，再把紀錄檔從buffer 中flush 到磁碟中。

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit=1，每次commit都會把redo log從redo log buffer寫入到system，並fsync重新整理到磁碟檔案中。
innodb_flush_log_at_trx_commit=2，每次事務提交時MySQL會把紀錄檔從redo log buffer寫入到system，但只寫入到file system buffer，由系統內部來fsync到磁碟檔案。如果資料庫範例crash，不會丟失redo log，但是如果伺服器crash，由於file system buffer還來不及fsync到磁碟檔案，所以會丟失這一部分的資料。
innodb_flush_log_at_trx_commit=0，事務發生過程，紀錄檔一直激勵在redo log buffer中，跟其他設定一樣，但是在事務提交時，不產生redo 寫操作，而是MySQL內部每秒操作一次，從redo log buffer，把資料寫入到系統中去。如果發生crash，即丟失1s內的事務修改操作。

注意：由於程序排程策略問題,這個“每秒執行一次 flush(刷到磁碟)操作”並不是保證100%的“每秒”。

2.3 redo 空間管理

Redo log檔案以ib_logfile[number]命名，Redo log 以順序的方式寫入檔案檔案，寫滿時則回溯到第一個檔案，進行覆蓋寫。（但在做redo checkpoint時，也會更新第一個紀錄檔檔案的頭部checkpoint標記，所以嚴格來講也不算順序寫）。

實際上redo log有兩部分組成：redo log buffer 跟redo log file。buffer pool中把資料修改情況記錄到redo log buffer，出現以下情況，再把redo log刷下到redo log file：

Redo log buffer空間不足
事務提交（依賴innodb_flush_log_at_trx_commit引數設定）
後臺執行緒
做checkpoint
範例shutdown
binlog切換

3 undo及redo如何記錄事務

3.1 Undo + Redo事務的簡化過程

假設有A、B兩個資料，值分別為1,2，開始一個事務，事務的操作內容為：把1修改為3，2修改為4，那麼實際的記錄如下（簡化）：

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.事務提交

3.2 IO影響

Undo + Redo的設計主要考慮的是提升IO效能，增巨量資料庫吞吐量。可以看出，B D E G H，均是新增操作，但是B D E G 是緩衝到buffer區，只有G是增加了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中刪除掉。

3.3 恢復

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

A. 進行恢復時，只重做已經提交了的事務。

B. 進行恢復時，重做所有事務包括未提交的事務和回滾了的事務。然後通過Undo Log回滾那些

未提交的事務。

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>