redo log

事務(wù)的支持是數(shù)據(jù)庫(kù)區(qū)分文件系統(tǒng)的重要特征之一，事務(wù)的四大特性：

• 原子性：所有的操作要么都做，要么都不做，不可分割。
• 一致性：數(shù)據(jù)庫(kù)從一種狀態(tài)變成另一種狀態(tài)的的結(jié)果最終是一致的，比如A給B轉(zhuǎn)賬500，A最終少了500，B最終多了500，但是A+B的值始終沒變。
• 隔離性：事務(wù)和事務(wù)之前相互隔離，互不干擾。
• 持久性：事務(wù)一旦提交，它對(duì)數(shù)據(jù)的變更是永久性的。
  

本篇文章主要說(shuō)說(shuō)持久性相關(guān)的知識(shí)。

當(dāng)我們?cè)谑聞?wù)中更新一條記錄的時(shí)候，比如：

update user set age=11 where user_id=1;

它的流程大概是這樣的：

• 先判斷user_id這條數(shù)據(jù)所在的頁(yè)是否在內(nèi)存里，如果不在的話，先從數(shù)據(jù)庫(kù)讀取到，然后加載到內(nèi)存中
• 修改內(nèi)存中的age為11
• 寫入redo log，并且redo log處于prepare狀態(tài)
• 寫入binlog
• 提交事務(wù)，redo log變成commit狀態(tài)

這里面有幾個(gè)關(guān)鍵的點(diǎn)：redo log是什么？為什么需要redo log？prepare狀態(tài)的redo log是什么？redo log和binlog是否可以只選其一...?帶著這一系列的問題，我們來(lái)揭開redo log的面紗。

為什么要先更新內(nèi)存數(shù)據(jù)，不直接更新磁盤數(shù)據(jù)？

我們?yōu)槭裁床幻看胃聰?shù)據(jù)的時(shí)候，直接更新對(duì)應(yīng)的磁盤數(shù)據(jù)？首先我們知道磁盤IO是緩慢的，內(nèi)存是快速的，兩者的速度不是一個(gè)量級(jí)的，那么針對(duì)緩慢的磁盤IO，出現(xiàn)了索引，通過(guò)索引哪怕數(shù)據(jù)成百上千萬(wàn)我們依然可以在磁盤上很快速的找我們的數(shù)據(jù)，這就是索引的作用。但是索引也需要維護(hù)，并不是一成不變的，當(dāng)我們插入一條新數(shù)據(jù)A的時(shí)候，由于這條數(shù)據(jù)要插入在已存在的數(shù)據(jù)B之后，那么就要移動(dòng)B數(shù)據(jù)，讓出一個(gè)位置給A，這個(gè)有一定的開銷。更糟糕的是，本來(lái)要插入的頁(yè)已經(jīng)滿了，那么就要申請(qǐng)一個(gè)新的頁(yè)，然后挪一部分?jǐn)?shù)據(jù)過(guò)去，這叫做頁(yè)的分裂，這個(gè)開銷更大。如果我們的sql變更是直接修改磁盤的數(shù)據(jù)，恰巧正好出現(xiàn)上面的問題，那么此時(shí)的效率就會(huì)很低，嚴(yán)重的話會(huì)造成超時(shí)，這也是上面更新的過(guò)程為什么先要加載對(duì)應(yīng)的數(shù)據(jù)頁(yè)到內(nèi)存中，然后先更新內(nèi)存中的數(shù)據(jù)的原因。對(duì)于mysql來(lái)說(shuō)，所有的變更都必須先更新緩沖池中的數(shù)據(jù)，然后緩沖池中的臟頁(yè)會(huì)以一定的頻率被刷入磁盤（checkPoint機(jī)制），通過(guò)緩沖池來(lái)優(yōu)化CPU和磁盤之間的鴻溝，這樣就可以保證整體的性能不會(huì)下降太快。

為什么需要redo log？

緩沖池可以幫助我們消除CPU和磁盤之間的鴻溝，checkpoint機(jī)制可以保證數(shù)據(jù)的最終落盤，然而由于checkpoint并不是每次變更的時(shí)候就觸發(fā)的，而是master線程隔一段時(shí)間去處理的。所以最壞的情況就是剛寫完緩沖池，數(shù)據(jù)庫(kù)宕機(jī)了，那么這段數(shù)據(jù)就是丟失的，無(wú)法恢復(fù)。這樣的話就不滿足ACID中的D，為了解決這種情況下的持久化問題，InnoDB引擎的事務(wù)采用了WAL技術(shù)（Write-Ahead Logging），這種技術(shù)的思想就是先寫日志，再寫磁盤，只有日志寫入成功，才算事務(wù)提交成功，這里的日志就是redo log。當(dāng)發(fā)生宕機(jī)且數(shù)據(jù)未刷到磁盤的時(shí)候，可以通過(guò)redo log來(lái)恢復(fù)，保證ACID中的D，這就是redo log的作用。

redo log是如何實(shí)現(xiàn)的？

redo log的寫入并不是直接寫入磁盤的，redo log也有緩沖區(qū)的，叫做redo log buffer（重做日志緩沖），InnoDB引擎會(huì)在寫redo log的時(shí)候先寫redo log buffer，然后也是以一定的頻率刷入到真正的redo log中，redo log buffer一般不需要特別大，它只是一個(gè)臨時(shí)的容器，master線程會(huì)每秒將redo log buffer刷到redo log文件中，因此我們只要保證redo log buffer能夠存下1s內(nèi)的事務(wù)變更的數(shù)據(jù)量即可，以mysql5.7.23為例，這個(gè)默認(rèn)是16M。

mysql> show variables like '%innodb_log_buffer_size%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+

16M的buffer足夠應(yīng)對(duì)大部分應(yīng)用了，buffer同步到redo log的策略主要有如下幾個(gè)：

• master線程每秒將buffer刷到到redo log中
• 每個(gè)事務(wù)提交的時(shí)候會(huì)將buffer刷到redo log中
• 當(dāng)buffer剩余空間小于1/2時(shí)，會(huì)被刷到redo log中

需要注意的是redo log buffer刷到redo log的過(guò)程并不是真正的刷到磁盤中去了，只是刷入到os cache中去，這是現(xiàn)代操作系統(tǒng)為了提高文件寫入的效率做的一個(gè)優(yōu)化，真正的寫入會(huì)交給系統(tǒng)自己來(lái)決定（比如os cache足夠大了）。那么對(duì)于InnoDB來(lái)說(shuō)就存在一個(gè)問題，如果交給系統(tǒng)來(lái)fsync，同樣如果系統(tǒng)宕機(jī)，那么數(shù)據(jù)也丟失了（雖然整個(gè)系統(tǒng)宕機(jī)的概率還是比較小的）。針對(duì)這種情況，InnoDB給出innodb_flush_log_at_trx_commit策略，讓用戶自己決定使用哪個(gè)。

mysql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+

• 0：表示事務(wù)提交后，不進(jìn)行fsync，而是由master每隔1s進(jìn)行一次重做日志的fysnc
• 1：默認(rèn)值，每次事務(wù)提交的時(shí)候同步進(jìn)行fsync
• 2：寫入os cache后，交給操作系統(tǒng)自己決定什么時(shí)候fsync

從3種刷入策略來(lái)說(shuō)：

2肯定是效率最高的，但是只要操作系統(tǒng)發(fā)生宕機(jī)，那么就會(huì)丟失os cache中的數(shù)據(jù)，這種情況下無(wú)法滿足ACID中的D

0的話，是一種折中的做法，它的IO效率理論是高于1的，低于2的，它的數(shù)據(jù)安全性理論是要低于1的，高于2的，這種策略也有丟失數(shù)據(jù)的風(fēng)險(xiǎn)，也無(wú)法保證D。

1是默認(rèn)值，可以保證D，數(shù)據(jù)絕對(duì)不會(huì)丟失，但是效率最差的。個(gè)人建議使用默認(rèn)值，雖然操作系統(tǒng)宕機(jī)的概率理論小于數(shù)據(jù)庫(kù)宕機(jī)的概率，但是一般既然使用了事務(wù)，那么數(shù)據(jù)的安全應(yīng)該是相對(duì)來(lái)說(shuō)更重要些。

redo log是對(duì)頁(yè)的物理修改，第x頁(yè)的第x位置修改成xx，比如：

page(2,4),offset 64,value 2

在InnoDB引擎中，redo log都是以512字節(jié)為單位進(jìn)行存儲(chǔ)的，每個(gè)存儲(chǔ)的單位我們稱之為redo log block（重做日志塊），若一個(gè)頁(yè)中存儲(chǔ)的日志量大于512字節(jié)，那么就需要邏輯上切割成多個(gè)block進(jìn)行存儲(chǔ)。

一個(gè)redo log block是由日志頭、日志體、日志尾組成。日志頭占用12字節(jié)，日志尾占用8字節(jié)，所以一個(gè)block真正能存儲(chǔ)的數(shù)據(jù)就是512-12-8=492字節(jié)。 

 多個(gè)redo log block組成了我們的redo log。 

每個(gè)redo log默認(rèn)大小為48M：

mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name        | Value    |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+

InnoDB默認(rèn)2個(gè)redo log組成一個(gè)log組，真正工作的就是這個(gè)log組。

mysql> show variables like 'innodb_log_files_in_group';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_log_files_in_group | 2     |
+---------------------------+-------+
#ib_logfile0
#ib_logfile1

當(dāng)ib_logfile0寫完之后，會(huì)寫ib_logfile1，當(dāng)ib_logfile1寫完之后，會(huì)重新寫ib_logfile0...，就這樣一直不停的循環(huán)寫。

為什么一個(gè)block設(shè)計(jì)成512字節(jié)？

這個(gè)和磁盤的扇區(qū)有關(guān)，機(jī)械磁盤默認(rèn)的扇區(qū)就是512字節(jié)，如果你要寫入的數(shù)據(jù)大于512字節(jié)，那么要寫入的扇區(qū)肯定不止一個(gè)，這時(shí)就要涉及到盤片的轉(zhuǎn)動(dòng)，找到下一個(gè)扇區(qū)，假設(shè)現(xiàn)在需要寫入兩個(gè)扇區(qū)A和B，如果扇區(qū)A寫入成功，而扇區(qū)B寫入失敗，那么就會(huì)出現(xiàn)非原子性的寫入，而如果每次只寫入和扇區(qū)的大小一樣的512字節(jié)，那么每次的寫入都是原子性的。

為什么要兩段式提交？

從上文我們知道，事務(wù)的提交要先寫redo log(prepare)，再寫binlog，最后再提交(commit)。這里為什么要有個(gè)prepare的動(dòng)作？redo log直接commit狀態(tài)不行嗎？假設(shè)redo log直接提交，在寫binlog的時(shí)候，發(fā)生了crash，這時(shí)binlog就沒有對(duì)應(yīng)的數(shù)據(jù)，那么所有依靠binlog來(lái)恢復(fù)數(shù)據(jù)的slave，就沒有對(duì)應(yīng)的數(shù)據(jù)，導(dǎo)致主從不一致。所以需要通過(guò)兩段式（2pc）提交來(lái)保證redo log和binlog的一致性是非常有必要的。具體的步驟是：處于prepare狀態(tài)的redo log，會(huì)記錄2PC的XID，binlog寫入后也會(huì)記錄2PC的XID，同時(shí)會(huì)在redo log上打上commit標(biāo)識(shí)。

redo log和bin log是否可以只需要其中一個(gè)？

不可以。redo log本身大小是固定的，在寫滿之后，會(huì)重頭開始寫，會(huì)覆蓋老數(shù)據(jù)，因?yàn)閞edo log無(wú)法保存所有數(shù)據(jù)，所以在主從模式下，想要通過(guò)redo log來(lái)同步數(shù)據(jù)給從庫(kù)是行不通的。那么binlog是一定需要的，binlog是mysql的server層產(chǎn)生的，和存儲(chǔ)引擎無(wú)關(guān)，binglog又叫歸檔日志，當(dāng)一個(gè)binlog file寫滿之后，會(huì)寫入到一個(gè)新的binlog file中。所以我們是不是只需要binlog就行了？redo log可以不需要？當(dāng)然也不行，redo log的作用是提供crash-safe的能力，首先對(duì)于一個(gè)數(shù)據(jù)的修改，是先修改緩沖池中的數(shù)據(jù)頁(yè)的，這時(shí)修改的數(shù)據(jù)并沒有真正的落盤，這主要是因?yàn)榇疟P的離散讀寫能力效率低，真正落盤的工作交給master線程定期來(lái)處理，好處就是master可以一次性把多個(gè)修改一起寫入磁盤。那么此時(shí)就有一個(gè)問題，當(dāng)事務(wù)commit之后，數(shù)據(jù)在緩沖區(qū)的臟頁(yè)中，還沒來(lái)的及刷入磁盤，此時(shí)數(shù)據(jù)庫(kù)發(fā)生了崩潰，那么這條commit的數(shù)據(jù)即使在數(shù)據(jù)庫(kù)恢復(fù)后，也無(wú)法還原，并不能滿足ACID中的D，然后就有了redo log，從流程來(lái)看，一個(gè)事務(wù)的提交必須保證redo log的寫入成功，只有redo log寫入成功才算事務(wù)提交成功，redo log大部分情況是順序?qū)懙拇疟P，所以它的效率要高很多。當(dāng)commit后發(fā)生crash的情況下，我們可以通過(guò)redo log來(lái)恢復(fù)數(shù)據(jù)，這也是為什么需要redo log的原因。但是事務(wù)的提交也需要binlog的寫入成功，那為什么不可以通過(guò)binlog來(lái)恢復(fù)未落盤的數(shù)據(jù)？這是因?yàn)閎inlog不知道哪些數(shù)據(jù)落盤了，所以不知道哪些數(shù)據(jù)需要恢復(fù)。對(duì)于redo log而言，在數(shù)據(jù)落盤后對(duì)應(yīng)的redo log中的數(shù)據(jù)會(huì)被刪除，那么在數(shù)據(jù)庫(kù)重啟后，只要把redo log中剩下的數(shù)據(jù)都恢復(fù)就行了。

crash后是如何恢復(fù)的？

通過(guò)兩段式提交我們知道redo log和binlog在各個(gè)階段會(huì)被打上prepare或者commit的標(biāo)識(shí)，同時(shí)還會(huì)記錄事務(wù)的XID，有了這些數(shù)據(jù)，在數(shù)據(jù)庫(kù)重啟的時(shí)候，會(huì)先去redo log里檢查所有的事務(wù)，如果redo log的事務(wù)處于commit狀態(tài)，那么說(shuō)明在commit后發(fā)生了crash，此時(shí)直接把redo log的數(shù)據(jù)恢復(fù)就行了，如果redo log是prepare狀態(tài)，那么說(shuō)明commit之前發(fā)生了crash，此時(shí)binlog的狀態(tài)決定了當(dāng)前事務(wù)的狀態(tài)，如果binlog中有對(duì)應(yīng)的XID，說(shuō)明binlog已經(jīng)寫入成功，只是沒來(lái)的及提交，此時(shí)再次執(zhí)行commit就行了，如果binlog中找不到對(duì)應(yīng)的XID，說(shuō)明binlog沒寫入成功就crash了，那么此時(shí)應(yīng)該執(zhí)行回滾。

undo log

redo log是事務(wù)持久性的保證，undo log是事務(wù)原子性的保證。在事務(wù)中更新數(shù)據(jù)的前置操作其實(shí)是要先寫入一個(gè)undo log中的，所以它的流程大致如下：

什么情況下會(huì)生成undo log？

undo log的作用就是mvcc（多版本控制）和回滾，我們這里主要說(shuō)回滾，當(dāng)我們?cè)谑聞?wù)里insert、update、delete某些數(shù)據(jù)的時(shí)候，就會(huì)產(chǎn)生對(duì)應(yīng)的undo log，當(dāng)我們執(zhí)行回滾時(shí)，通過(guò)undo log就可以回到事務(wù)開始的樣子。需要注意的是回滾并不是修改的物理頁(yè)，而是邏輯的恢復(fù)到最初的樣子，比如一個(gè)數(shù)據(jù)A，在事務(wù)里被你修改成B，但是此時(shí)有另一個(gè)事務(wù)已經(jīng)把它修改成了C，如果回滾直接修改數(shù)據(jù)頁(yè)把數(shù)據(jù)改成A，那么C就被覆蓋了。

對(duì)于InnoDB引擎來(lái)說(shuō)，每個(gè)行記錄除了記錄本身的數(shù)據(jù)之外，還有幾個(gè)隱藏的列：

• DB_ROW_ID：如果沒有為表顯式的定義主鍵，并且表中也沒有定義唯一索引，那么InnoDB會(huì)自動(dòng)為表添加一個(gè)row_id的隱藏列作為主鍵。
• DB_TRX_ID：每個(gè)事務(wù)都會(huì)分配一個(gè)事務(wù)ID，當(dāng)對(duì)某條記錄發(fā)生變更時(shí)，就會(huì)將這個(gè)事務(wù)的事務(wù)ID寫入trx_id中。
• DB_ROLL_PTR：回滾指針，本質(zhì)上就是指向 undo log 的指針。

當(dāng)我們執(zhí)行INSERT時(shí)：

begin;
INSERT INTO user (name) VALUES ("tom")

插入的數(shù)據(jù)都會(huì)生一條insert undo log，并且數(shù)據(jù)的回滾指針會(huì)指向它。undo log會(huì)記錄undo log的序號(hào)、插入主鍵的列和值...，那么在進(jìn)行rollback的時(shí)候，通過(guò)主鍵直接把對(duì)應(yīng)的數(shù)據(jù)刪除即可。

對(duì)于更新的操作會(huì)產(chǎn)生update undo log，并且會(huì)分更新主鍵的和不更新的主鍵的，假設(shè)現(xiàn)在執(zhí)行：

UPDATE user SET name="Sun" WHERE id=1;

 這時(shí)會(huì)把老的記錄寫入新的undo log，讓回滾指針指向新的undo log，它的undo no是1，并且新的undo log會(huì)指向老的undo log（undo no=0）。

假設(shè)現(xiàn)在執(zhí)行：

UPDATE user SET id=2 WHERE id=1;

對(duì)于更新主鍵的操作，會(huì)先把原來(lái)的數(shù)據(jù)deletemark標(biāo)識(shí)打開，這時(shí)并沒有真正的刪除數(shù)據(jù)，真正的刪除會(huì)交給清理線程去判斷，然后在后面插入一條新的數(shù)據(jù)，新的數(shù)據(jù)也會(huì)產(chǎn)生undo log，并且undo log的序號(hào)會(huì)遞增。

可以發(fā)現(xiàn)每次對(duì)數(shù)據(jù)的變更都會(huì)產(chǎn)生一個(gè)undo log，當(dāng)一條記錄被變更多次時(shí)，那么就會(huì)產(chǎn)生多條undo log，undo log記錄的是變更前的日志，并且每個(gè)undo log的序號(hào)是遞增的，那么當(dāng)要回滾的時(shí)候，按照序號(hào)依次向前推，就可以找到我們的原始數(shù)據(jù)了。

undo log是如何回滾的？

以上面的例子來(lái)說(shuō)，假設(shè)執(zhí)行rollback，那么對(duì)應(yīng)的流程應(yīng)該是這樣：

• 通過(guò)undo no=3的日志把id=2的數(shù)據(jù)刪除
• 通過(guò)undo no=2的日志把id=1的數(shù)據(jù)的deletemark還原成0
• 通過(guò)undo no=1的日志把id=1的數(shù)據(jù)的name還原成Tom
• 通過(guò)undo no=0的日志把id=1的數(shù)據(jù)刪除

undo log存在什么地方？

InnoDB對(duì)undo log的管理采用段的方式，也就是回滾段，每個(gè)回滾段記錄了1024個(gè)undo log segment，InnoDB引擎默認(rèn)支持128個(gè)回滾段

mysql> show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_undo_logs | 128   |
+------------------+-------+

那么能支持的最大并發(fā)事務(wù)就是128*1024。每個(gè)undo log segment就像維護(hù)一個(gè)有1024個(gè)元素的數(shù)組。

當(dāng)我們開啟個(gè)事務(wù)需要寫undo log的時(shí)候，就得先去undo log segment中去找到一個(gè)空閑的位置，當(dāng)有空位的時(shí)候，就會(huì)去申請(qǐng)undo頁(yè)，最后會(huì)在這個(gè)申請(qǐng)到的undo頁(yè)中進(jìn)行undo log的寫入。我們知道m(xù)ysql默認(rèn)一頁(yè)的大小是16k。

mysql> show variables like '%innodb_page_size%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+

那么為一個(gè)事務(wù)就分配一個(gè)頁(yè)，其實(shí)是非常浪費(fèi)的（除非你的事物非常長(zhǎng)），假設(shè)你的應(yīng)用的TPS為1000，那么1s就需要1000個(gè)頁(yè)，大概需要16M的存儲(chǔ)，1分鐘大概需要1G的存儲(chǔ)...，如果照這樣下去除非mysql清理的非常勤快，否則隨著時(shí)間的推移，磁盤空間會(huì)增長(zhǎng)的非?？?，而且很多空間都是浪費(fèi)的。于是undo頁(yè)就被設(shè)計(jì)的可以重用了，當(dāng)事務(wù)提交時(shí)，并不會(huì)立刻刪除undo頁(yè)，因?yàn)橹赜?，這個(gè)undo頁(yè)它可能不干凈了，所以這個(gè)undo頁(yè)可能混雜著其他事務(wù)的undo log。undo log在commit后，會(huì)被放到一個(gè)鏈表中，然后判斷undo頁(yè)的使用空間是否小于3/4，如果小于3/4的話，則表示當(dāng)前的undo頁(yè)可以被重用，那么它就不會(huì)被回收，其他事務(wù)的undo log可以記錄在當(dāng)前undo頁(yè)的后面。由于undo log是離散的，所以清理對(duì)應(yīng)的磁盤空間時(shí)，效率不是那么高。

到此這篇關(guān)于一文搞懂MySQL持久化和回滾的原理的文章就介紹到這了,更多相關(guān)MySQL持久化和回滾內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！