4. undo日志

undo log（撤銷日志或回滾日志）記錄了事務(wù)發(fā)生之前的數(shù)據(jù)狀態(tài)，分為insert undo log和update undo log。

如果修改數(shù)據(jù)時(shí)出現(xiàn)異常，可以用 undo log來實(shí)現(xiàn)回滾操作（保持原子性）?？梢岳斫鉃閡ndo日志記錄的是反向的操作，比如INSERT操作會(huì)記錄DELETE，UPDATE會(huì)記錄UPDATE之前的值，和redo日志記錄在哪個(gè)物理頁面做了什么操作不同，所以這是一種邏輯格式的日志。

undo日志和redo日志與事務(wù)密切相關(guān)，被統(tǒng)稱為「事務(wù)日志」。

關(guān)于undo日志，我們目前只需要了解這么多即可

5. SQL更新語句的執(zhí)行總結(jié)——初版

有了事務(wù)日志之后，我們來簡(jiǎn)單總結(jié)一下更新操作的流程，這是一個(gè)簡(jiǎn)化的過程。

name 原值是chanmufeng。

update t_user_innodb set name ='chanmufeng1994' where id = 1;

1. 事務(wù)開始，從內(nèi)存（Buffer Pool）或磁盤取到包含這條數(shù)據(jù)的數(shù)據(jù)頁，返回給 Server 的執(zhí)行器；
2. Server 的執(zhí)行器修改數(shù)據(jù)頁的這一行數(shù)據(jù)的值為 chanmufeng1994；
3. 記錄 name=chanmufeng 到undo log；
4. 記錄 name=chanmufeng1994到redo log；
5. 調(diào)用存儲(chǔ)引擎接口，記錄數(shù)據(jù)頁到Buffer Pool（修改 name=penyuyan）；
6. 事務(wù)提交。

6. binlog日志

之前我們講過，從MySQL整體架構(gòu)來看，其實(shí)可以分成兩部分

• Server 層，它主要做的是 MySQL功能層面的事情，比如處理連接、解析優(yōu)化等；
• 存儲(chǔ)引擎層，負(fù)責(zé)存儲(chǔ)相關(guān)的具體事宜。

redo日志是InnoDB存儲(chǔ)引擎特有的日志，而Server層也有自己的日志，稱為 binlog（歸檔日志），它可以被所有存儲(chǔ)引擎使用。

6.1 為什么有了redo日志還需要 binlog？

我想你可能會(huì)問出這個(gè)問題，實(shí)際上，更準(zhǔn)確的問法是為什么有了binlog還需要有redo日志？主要有以下幾個(gè)原因。

1. 因?yàn)樽铋_始MySQL里并沒有InnoDB存儲(chǔ)引擎。MySQL自帶的引擎是MyISAM，但是 MyISAM沒有崩潰恢復(fù)的能力，InnoDB后來以插件的形式被引入，順便帶來了redo日志；
2. binlog日志是用來歸檔的，binlog以事件的形式記錄了所有的 DDL和 DML 語句（因?yàn)樗涗浀氖遣僮鞫皇?數(shù)據(jù)值，屬于邏輯日志），但是不具備宕機(jī)恢復(fù)的功能，因?yàn)榭赡軟]有來得及刷新臟頁，造成臟頁數(shù)據(jù)的丟失，而這些操作也沒有保存到binlog中從而造成數(shù)據(jù)丟失；
3. binlog記錄的是關(guān)于一個(gè)事務(wù)的具體操作內(nèi)容，即該日志是邏輯日志。而redo日志記錄的是關(guān)于每個(gè)頁的更改的物理情況。功能壓根不是一回事兒。

6.2 binlog日志的作用

6.2.1 主從復(fù)制

binlog是實(shí)現(xiàn)MySQL主從復(fù)制功能的核心組件。

master節(jié)點(diǎn)會(huì)將所有的寫操作記錄到binlog中，slave節(jié)點(diǎn)會(huì)有專門的I/O線程讀取master節(jié)點(diǎn)的binlog，將寫操作同步到當(dāng)前所在的slave節(jié)點(diǎn)。

6.2.2 數(shù)據(jù)恢復(fù)

假如你在閱讀這篇文章的時(shí)候覺得我寫得實(shí)在太好，拍案叫絕的時(shí)候一不小心把公司的數(shù)據(jù)庫(kù)給刪了，你該怎么做才能恢復(fù)到你刪庫(kù)之前的那個(gè)時(shí)刻的狀態(tài)？

這個(gè)時(shí)候就要用到binlog了，前提是binlog沒有被刪除，否則，神仙也救不了你了。

通常情況下，公司會(huì)定期對(duì)數(shù)據(jù)庫(kù)進(jìn)行全量備份，可能隔一個(gè)月，一周，甚至可能每天都備份一次。運(yùn)氣好的話你可以使用前一天的全量備份，恢復(fù)到前一天的某時(shí)刻狀態(tài)（或者一周、一月之前），然后從全量備份的時(shí)刻開始，從binlog中提取該時(shí)刻之后（前提是你的binlog里面存放了這段時(shí)間的日志）的所有寫操作（當(dāng)然，你得過濾掉你的刪庫(kù)操作），然后進(jìn)行操作回放就可以了。

是不是很簡(jiǎn)單？

問題又來了。再看一眼我們的更新語句。

update t_user_innodb set name ='chanmufeng1994' where id = 1;

假如這條更新語句已經(jīng)被寫入到了redo日志，還沒來得及寫binlog的時(shí)候，MySQL宕機(jī)重啟了，我們看一下會(huì)發(fā)生什么。

因?yàn)閞edo日志可以在重啟的時(shí)候用于恢復(fù)數(shù)據(jù)，所以寫入磁盤的是chanmufeng1994。但是binlog里面沒有記錄這個(gè)邏輯日志，所以這時(shí)候用binlog去恢復(fù)數(shù)據(jù)或者同步到從庫(kù)，就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

所以在寫兩個(gè)日志的情況下，就類似于「分布式事務(wù)」的情況，如果你不清楚分布式事務(wù)是個(gè)什么東西也沒關(guān)系，我在之后的文章會(huì)介紹到。能夠明確的就是redo日志和binlog日志如果單純依次進(jìn)行提交是無法保證兩種日志都寫成功或者都寫失敗的。

我們需要「兩階段提交」。

6.3 兩階段提交

兩階段提交不是MySQL的專利，兩階段提交是一種跨系統(tǒng)維持?jǐn)?shù)據(jù)邏輯一致性的常見方案，尤其在分布式事務(wù)上，所以請(qǐng)讀者重點(diǎn)體會(huì)思想

我們把redo日志的提交分成兩步，兩步中redo日志的狀態(tài)分別是prepare和commit。步驟如下

1. InnoDB存儲(chǔ)引擎將更改更新到內(nèi)存中后，同時(shí)將這個(gè)更新操作記錄到redo日志里面，此時(shí)redo日志處于prepare狀態(tài)；
2. 執(zhí)行器生成這個(gè)操作的binlog，并將binlog刷盤；
3. 執(zhí)行器調(diào)用InnoDB的提交事務(wù)接口，InnoDB把剛剛寫入的redo日志改成commit狀態(tài)。至此，所有操作完成。

加上兩階段提交之后我們?cè)賮砜匆幌耂QL更新語句的執(zhí)行流程。

7. SQL更新語句的執(zhí)行總結(jié)——終版

1. 客戶端發(fā)送更新命令到MySQL服務(wù)器，經(jīng)過處理連接、解析優(yōu)化等步驟；
2. Server層向InnoDB存儲(chǔ)引擎要id=1的這條記錄；
3. 存儲(chǔ)引擎先從緩存中查找這條記錄，有的話直接返回，沒有則從磁盤加載到緩存中然后返回；
4. Server層執(zhí)行器修改這條記錄的name字段值；
5. 存儲(chǔ)引擎更新修改到內(nèi)存中；
6. 存儲(chǔ)引擎記錄redo日志，并將狀態(tài)設(shè)置為prepare狀態(tài)；
7. 存儲(chǔ)引擎通知執(zhí)行器，修改完畢，可以進(jìn)行事務(wù)提交；
8. Server先寫了個(gè)binlog；
9. Server提交事務(wù)；
10. 存儲(chǔ)引擎將redo日志中和當(dāng)前事務(wù)相關(guān)的記錄狀態(tài)設(shè)置為commit狀態(tài)。