前言

在數(shù)據(jù)庫(kù)系統(tǒng)中，既有存放數(shù)據(jù)的文件，也有存放日志的文件。日志在內(nèi)存中也是有緩存Log buffer，也有磁盤(pán)文件log file，本文主要描述存放日志的文件。

MySQL中的日志文件，有這么兩類常常討論到：undo日志與redo日志。

1 undo

1.1 undo是什么

undo日志用于存放數(shù)據(jù)修改被修改前的值，假設(shè)修改 tba 表中 id=2的行數(shù)據(jù)，把Name='B' 修改為Name = 'B2' ，那么undo日志就會(huì)用來(lái)存放Name='B'的記錄，如果這個(gè)修改出現(xiàn)異常，可以使用undo日志來(lái)實(shí)現(xiàn)回滾操作，保證事務(wù)的一致性。

對(duì)數(shù)據(jù)的變更操作，主要來(lái)自 INSERT UPDATE DELETE，而UNDO LOG中分為兩種類型，一種是 INSERT_UNDO（INSERT操作），記錄插入的唯一鍵值；一種是 UPDATE_UNDO（包含UPDATE及DELETE操作），記錄修改的唯一鍵值以及old column記錄。

1.2 undo參數(shù)

MySQL跟undo有關(guān)的參數(shù)設(shè)置有這些：

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文件的大小，當(dāng)啟動(dòng)了innodb_undo_log_truncate 時(shí)，undo tablespace 超過(guò)innodb_max_undo_log_size 閥值時(shí)才會(huì)去嘗試truncate。該值默認(rèn)大小為1G，truncate后的大小默認(rèn)為10M。

• innodb_undo_tablespaces 

設(shè)置undo獨(dú)立表空間個(gè)數(shù)，范圍為0-128， 默認(rèn)為0，0表示表示不開(kāi)啟獨(dú)立undo表空間 且 undo日志存儲(chǔ)在ibdata文件中。該參數(shù)只能在最開(kāi)始初始化MySQL實(shí)例的時(shí)候指定，如果實(shí)例已創(chuàng)建，這個(gè)參數(shù)是不能變動(dòng)的，如果在數(shù)據(jù)庫(kù)配置文 件 .cnf 中指定innodb_undo_tablespaces 的個(gè)數(shù)大于實(shí)例創(chuàng)建時(shí)的指定個(gè)數(shù)，則會(huì)啟動(dòng)失敗，提示該參數(shù)設(shè)置有誤。

如果設(shè)置了該參數(shù)為n（n>0），那么就會(huì)在undo目錄下創(chuàng)建n個(gè)undo文件（undo001，undo002 ...... undo n），每個(gè)文件默認(rèn)大小為10M.

什么時(shí)候需要來(lái)設(shè)置這個(gè)參數(shù)呢？

當(dāng)DB寫(xiě)壓力較大時(shí)，可以設(shè)置獨(dú)立UNDO表空間，把UNDO LOG從ibdata文件中分離開(kāi)來(lái)，指定 innodb_undo_directory目錄存放，可以制定到高速磁盤(pán)上，加快UNDO LOG 的讀寫(xiě)性能。

• innodb_undo_log_truncate

InnoDB的purge線程，根據(jù)innodb_undo_log_truncate設(shè)置開(kāi)啟或關(guān)閉、innodb_max_undo_log_size的參數(shù)值，以及truncate的頻率來(lái)進(jìn)行空間回收和 undo file 的重新初始化。

 該參數(shù)生效的前提是，已設(shè)置獨(dú)立表空間且獨(dú)立表空間個(gè)數(shù)大于等于2個(gè)。

purge線程在truncate undo log file的過(guò)程中，需要檢查該文件上是否還有活動(dòng)事務(wù)，如果沒(méi)有，需要把該undo log file標(biāo)記為不可分配，這個(gè)時(shí)候，undo log 都會(huì)記錄到其他文件上，所以至少需要2個(gè)獨(dú)立表空間文件，才能進(jìn)行truncate 操作，標(biāo)注不可分配后，會(huì)創(chuàng)建一個(gè)獨(dú)立的文件undo_<space_id>_trunc.log，記錄現(xiàn)在正在truncate 某個(gè)undo log文件，然后開(kāi)始初始化undo log file到10M，操作結(jié)束后，刪除表示truncate動(dòng)作的 undo_<space_id>_trunc.log 文件，這個(gè)文件保證了即使在truncate過(guò)程中發(fā)生了故障重啟數(shù)據(jù)庫(kù)服務(wù)，重啟后，服務(wù)發(fā)現(xiàn)這個(gè)文件，也會(huì)繼續(xù)完成truncate操作，刪除文件結(jié)束后，標(biāo)識(shí)該undo log file可分配。

• innodb_purge_rseg_truncate_frequency

用于控制purge回滾段的頻度，默認(rèn)為128。假設(shè)設(shè)置為n，則說(shuō)明，當(dāng)Innodb Purge操作的協(xié)調(diào)線程 purge事務(wù)128次時(shí)，就會(huì)觸發(fā)一次History purge，檢查當(dāng)前的undo log 表空間狀態(tài)是否會(huì)觸發(fā)truncate。

1.3 undo空間管理

如果需要設(shè)置獨(dú)立表空間，需要在初始化數(shù)據(jù)庫(kù)實(shí)例的時(shí)候，指定獨(dú)立表空間的數(shù)量。

UNDO內(nèi)部由多個(gè)回滾段組成，即 Rollback segment，一共有128個(gè)，保存在ibdata系統(tǒng)表空間中，分別從resg slot0 - resg slot127，每一個(gè)resg slot，也就是每一個(gè)回滾段，內(nèi)部由1024個(gè)undo segment 組成。

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

• slot 0 ，預(yù)留給系統(tǒng)表空間；
• slot 1- 32，預(yù)留給臨時(shí)表空間，每次數(shù)據(jù)庫(kù)重啟的時(shí)候，都會(huì)重建臨時(shí)表空間；
• slot33-127，如果有獨(dú)立表空間，則預(yù)留給UNDO獨(dú)立表空間；如果沒(méi)有，則預(yù)留給系統(tǒng)表空間；

回滾段中除去32個(gè)提供給臨時(shí)表事務(wù)使用，剩下的 128-32=96個(gè)回滾段，可執(zhí)行 96*1024 個(gè)并發(fā)事務(wù)操作，每個(gè)事務(wù)占用一個(gè) undo segment slot，注意，如果事務(wù)中有臨時(shí)表事務(wù)，還會(huì)在臨時(shí)表空間中的 undo segment slot 再占用一個(gè) undo segment slot，即占用2個(gè)undo segment slot。如果錯(cuò)誤日志中有：Cannot find a free slot for an undo log。則說(shuō)明并發(fā)的事務(wù)太多了，需要考慮下是否要分流業(yè)務(wù)。

回滾段（rollback segment ）采用 輪詢調(diào)度的方式來(lái)分配使用，如果設(shè)置了獨(dú)立表空間，那么就不會(huì)使用系統(tǒng)表空間回滾段中undo segment，而是使用獨(dú)立表空間的，同時(shí)，如果回顧段正在 Truncate操作，則不分配。

2 redo

2.1 redo是什么

當(dāng)數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)做修改的時(shí)候，需要把數(shù)據(jù)頁(yè)從磁盤(pán)讀到buffer pool中，然后在buffer pool中進(jìn)行修改，那么這個(gè)時(shí)候buffer pool中的數(shù)據(jù)頁(yè)就與磁盤(pán)上的數(shù)據(jù)頁(yè)內(nèi)容不一致，稱buffer pool的數(shù)據(jù)頁(yè)為dirty page 臟數(shù)據(jù)，如果這個(gè)時(shí)候發(fā)生非正常的DB服務(wù)重啟，那么這些數(shù)據(jù)還沒(méi)在內(nèi)存，并沒(méi)有同步到磁盤(pán)文件中（注意，同步到磁盤(pán)文件是個(gè)隨機(jī)IO），也就是會(huì)發(fā)生數(shù)據(jù)丟失，如果這個(gè)時(shí)候，能夠在有一個(gè)文件，當(dāng)buffer pool 中的data page變更結(jié)束后，把相應(yīng)修改記錄記錄到這個(gè)文件（注意，記錄日志是順序IO），那么當(dāng)DB服務(wù)發(fā)生crash的情況，恢復(fù)DB的時(shí)候，也可以根據(jù)這個(gè)文件的記錄內(nèi)容，重新應(yīng)用到磁盤(pán)文件，數(shù)據(jù)保持一致。

這個(gè)文件就是redo log ，用于記錄 數(shù)據(jù)修改后的記錄，順序記錄。它可以帶來(lái)這些好處：

• 當(dāng)buffer pool中的dirty page 還沒(méi)有刷新到磁盤(pán)的時(shí)候，發(fā)生crash，啟動(dòng)服務(wù)后，可通過(guò)redo log 找到需要重新刷新到磁盤(pán)文件的記錄；
• buffer pool中的數(shù)據(jù)直接flush到disk file，是一個(gè)隨機(jī)IO，效率較差，而把buffer pool中的數(shù)據(jù)記錄到redo log，是一個(gè)順序IO，可以提高事務(wù)提交的速度；

假設(shè)修改 tba 表中 id=2的行數(shù)據(jù)，把Name='B' 修改為Name = 'B2' ，那么redo日志就會(huì)用來(lái)存放Name='B2'的記錄，如果這個(gè)修改在flush 到磁盤(pán)文件時(shí)出現(xiàn)異常，可以使用redo log實(shí)現(xiàn)重做操作，保證事務(wù)的持久性。

這里注意下redo log 跟binary log 的區(qū)別，redo log 是存儲(chǔ)引擎層產(chǎn)生的，而binary log是數(shù)據(jù)庫(kù)層產(chǎn)生的。假設(shè)一個(gè)大事務(wù)，對(duì)tba做10萬(wàn)行的記錄插入，在這個(gè)過(guò)程中，一直不斷的往redo log順序記錄，而binary log不會(huì)記錄，知道這個(gè)事務(wù)提交，才會(huì)一次寫(xiě)入到binary log文件中。binary log的記錄格式有3種：row，statement跟mixed，不同格式記錄形式不一樣。

2.2 redo 參數(shù)

• innodb_log_files_in_group

redo log 文件的個(gè)數(shù)，命名方式如：ib_logfile0，iblogfile1... iblogfilen。默認(rèn)2個(gè)，最大100個(gè)。

• innodb_log_file_size

文件設(shè)置大小，默認(rèn)值為 48M，最大值為512G，注意最大值指的是整個(gè) redo log系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。

• innodb_log_group_home_dir

文件存放路徑

• innodb_log_buffer_size

Redo Log 緩存區(qū)，默認(rèn)8M，可設(shè)置1-8M。延遲事務(wù)日志寫(xiě)入磁盤(pán)，把redo log 放到該緩沖區(qū)，然后根據(jù) innodb_flush_log_at_trx_commit參數(shù)的設(shè)置，再把日志從buffer 中flush 到磁盤(pán)中。

• innodb_flush_log_at_trx_commit

• innodb_flush_log_at_trx_commit=1，每次commit都會(huì)把redo log從redo log buffer寫(xiě)入到system，并fsync刷新到磁盤(pán)文件中。
• innodb_flush_log_at_trx_commit=2，每次事務(wù)提交時(shí)MySQL會(huì)把日志從redo log buffer寫(xiě)入到system，但只寫(xiě)入到file system buffer，由系統(tǒng)內(nèi)部來(lái)fsync到磁盤(pán)文件。如果數(shù)據(jù)庫(kù)實(shí)例crash，不會(huì)丟失redo log，但是如果服務(wù)器crash，由于file system buffer還來(lái)不及fsync到磁盤(pán)文件，所以會(huì)丟失這一部分的數(shù)據(jù)。
• innodb_flush_log_at_trx_commit=0，事務(wù)發(fā)生過(guò)程，日志一直激勵(lì)在redo log buffer中，跟其他設(shè)置一樣，但是在事務(wù)提交時(shí)，不產(chǎn)生redo 寫(xiě)操作，而是MySQL內(nèi)部每秒操作一次，從redo log buffer，把數(shù)據(jù)寫(xiě)入到系統(tǒng)中去。如果發(fā)生crash，即丟失1s內(nèi)的事務(wù)修改操作。

• 注意：由于進(jìn)程調(diào)度策略問(wèn)題,這個(gè)“每秒執(zhí)行一次 flush(刷到磁盤(pán))操作”并不是保證100%的“每秒”。

2.3 redo 空間管理

Redo log文件以ib_logfile[number]命名，Redo log 以順序的方式寫(xiě)入文件文件，寫(xiě)滿時(shí)則回溯到第一個(gè)文件，進(jìn)行覆蓋寫(xiě)。（但在做redo checkpoint時(shí)，也會(huì)更新第一個(gè)日志文件的頭部checkpoint標(biāo)記，所以嚴(yán)格來(lái)講也不算順序?qū)懀?/p>

實(shí)際上redo log有兩部分組成：redo log buffer 跟redo log file。buffer pool中把數(shù)據(jù)修改情況記錄到redo log buffer，出現(xiàn)以下情況，再把redo log刷下到redo log file：

• Redo log buffer空間不足
• 事務(wù)提交（依賴innodb_flush_log_at_trx_commit參數(shù)設(shè)置）
• 后臺(tái)線程
• 做checkpoint
• 實(shí)例shutdown
• binlog切換

3 undo及redo如何記錄事務(wù)

3.1 Undo + Redo事務(wù)的簡(jiǎn)化過(guò)程

假設(shè)有A、B兩個(gè)數(shù)據(jù)，值分別為1,2，開(kāi)始一個(gè)事務(wù)，事務(wù)的操作內(nèi)容為：把1修改為3，2修改為4，那么實(shí)際的記錄如下（簡(jiǎn)化）：

  A.事務(wù)開(kāi)始.

  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寫(xiě)入磁盤(pán)。

  I.事務(wù)提交

3.2  IO影響

Undo + Redo的設(shè)計(jì)主要考慮的是提升IO性能，增大數(shù)據(jù)庫(kù)吞吐量。可以看出，B D E G H，均是新增操作，但是B D E G 是緩沖到buffer區(qū)，只有G是增加了IO操作，為了保證Redo Log能夠有比較好的IO性能，InnoDB 的 Redo Log的設(shè)計(jì)有以下幾個(gè)特點(diǎn)：

  A. 盡量保持Redo Log存儲(chǔ)在一段連續(xù)的空間上。因此在系統(tǒng)第一次啟動(dòng)時(shí)就會(huì)將日志文件的空間完全分配。 以順序追加的方式記錄Redo Log,通過(guò)順序IO來(lái)改善性能。

  B. 批量寫(xiě)入日志。日志并不是直接寫(xiě)入文件，而是先寫(xiě)入redo log buffer.當(dāng)需要將日志刷新到磁盤(pán)時(shí) (如事務(wù)提交),將許多日志一起寫(xiě)入磁盤(pán).

  C. 并發(fā)的事務(wù)共享Redo Log的存儲(chǔ)空間，它們的Redo Log按語(yǔ)句的執(zhí)行順序，依次交替的記錄在一起，以減少日志占用的空間。例如,Redo Log中的記錄內(nèi)容可能是這樣的：

     記錄1: <trx1, insert …>
     記錄2: <trx2, update …>
     記錄3: <trx1, delete …>
     記錄4: <trx3, update …>
     記錄5: <trx2, insert …>

  D. 因?yàn)镃的原因,當(dāng)一個(gè)事務(wù)將Redo Log寫(xiě)入磁盤(pán)時(shí)，也會(huì)將其他未提交的事務(wù)的日志寫(xiě)入磁盤(pán)。

  E. Redo Log上只進(jìn)行順序追加的操作，當(dāng)一個(gè)事務(wù)需要回滾時(shí)，它的Redo Log記錄也不會(huì)從Redo Log中刪除掉。

3.3 恢復(fù)

前面說(shuō)到未提交的事務(wù)和回滾了的事務(wù)也會(huì)記錄Redo Log，因此在進(jìn)行恢復(fù)時(shí),這些事務(wù)要進(jìn)行特殊的的處理。有2種不同的恢復(fù)策略：

  A. 進(jìn)行恢復(fù)時(shí)，只重做已經(jīng)提交了的事務(wù)。

  B. 進(jìn)行恢復(fù)時(shí)，重做所有事務(wù)包括未提交的事務(wù)和回滾了的事務(wù)。然后通過(guò)Undo Log回滾那些

     未提交的事務(wù)。

  MySQL數(shù)據(jù)庫(kù)InnoDB存儲(chǔ)引擎使用了B策略, InnoDB存儲(chǔ)引擎中的恢復(fù)機(jī)制有幾個(gè)特點(diǎn)：

  A. 在重做Redo Log時(shí)，并不關(guān)心事務(wù)性。 恢復(fù)時(shí)，沒(méi)有BEGIN，也沒(méi)有COMMIT,ROLLBACK的行為。也不關(guān)心每個(gè)日志是哪個(gè)事務(wù)的。盡管事務(wù)ID等事務(wù)相關(guān)的內(nèi)容會(huì)記入Redo Log，這些內(nèi)容只是被當(dāng)作要操作的數(shù)據(jù)的一部分。

  B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫(xiě)Redo Log之前將對(duì)應(yīng)的Undo Log寫(xiě)入磁盤(pán)。Undo和Redo Log的這種關(guān)聯(lián)，使得持久化變得復(fù)雜起來(lái)。為了降低復(fù)雜度，InnoDB將Undo Log看作數(shù)據(jù)，因此記錄Undo Log的操作也會(huì)記錄到redo log中。這樣undo log就可以象數(shù)據(jù)一樣緩存起來(lái)，而不用在redo log之前寫(xiě)入磁盤(pán)了。

     包含Undo Log操作的Redo Log，看起來(lái)是這樣的：
     記錄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. 到這里，還有一個(gè)問(wèn)題沒(méi)有弄清楚。既然Redo沒(méi)有事務(wù)性，那豈不是會(huì)重新執(zhí)行被回滾了的事務(wù)？

     確實(shí)是這樣。同時(shí)Innodb也會(huì)將事務(wù)回滾時(shí)的操作也記錄到redo log中?；貪L操作本質(zhì)上也是對(duì)數(shù)據(jù)進(jìn)行修改，因此回滾時(shí)對(duì)數(shù)據(jù)的操作也會(huì)記錄到Redo Log中。

     一個(gè)回滾了的事務(wù)的Redo Log，看起來(lái)是這樣的：

     記錄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>

一個(gè)被回滾了的事務(wù)在恢復(fù)時(shí)的操作就是先redo再undo，因此不會(huì)破壞數(shù)據(jù)的一致性。

總結(jié)

到此這篇關(guān)于mysql日志文件之undo log和redo log的文章就介紹到這了,更多相關(guān)mysql undo log和redo log內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論