談談傳說中的redo log是什麼？有啥用？

白日夢感覺作為研發同學的你可能真的沒必要了解摸清楚關於redo log的這些機制。專注於寫SQL完全能hold住日常的工作。

但是呢，感覺最好還是要了解一下，因為一般面試官都知道redo log是咋回事，其次是大家茶前飯後嘮嗑時也能多少能插幾句嘴。

文章公號首發！連載中！關注微信公號回覆：“抽獎” 還可參加抽?活動

一、引出 redo log 的作用

繼續我們的MySQL專題。首先回顧一下前面白日夢同你分享過的知識點。

前面我們一起學習了MySQL undo log相關的知識點，看下面這張腦圖：

磁碟上的資料檔案叫表空間檔案，表空間有挺多的，比如系統表空間、undo log 表空間、你也可以讓create出來的每張table都有自己單獨的表空間。總之MySQL會將表空間資料頁通過磁碟IO載入進快取頁中。

SQL執行器會執行你傳送給MySQL的SQL語句，MySQL為了提高的效能，對於增、刪、改這種操作都是在記憶體中完成的，所謂的記憶體就是上圖中BufferPool。比如上圖中的SQL執行器執行了一條update xxx where id = 1語句，然後這個id = 1資料行所在的資料頁就會被你修改成髒資料頁。

此外MySQL還有專門的後臺執行緒等其他機制負責將髒資料頁重新整理同步回磁碟。

二、思考一個問題：

你可以結合上圖然後想一下：萬一髒頁還沒來得及重新整理到磁碟中，MySQL就掛了，怎麼辦呢？

對於業務程式碼來說，方才執行的事務是OK的，甚至前端都接受到了請求成功的響應。那結果修改的資料沒同步回磁碟，MySQL當機了會不會導致真實資料和邏輯上的資料不一致呢？

其實不會的！

MySQL使用redo log解決了這個問題，redo故名思義：重做。

當發生事務（增、刪、改）時會導致快取頁變成髒頁，於此同時MySQL會將事務涉及到的：對 XXX表空間中的XXX資料頁XXX偏移量的地方做了XXX更新。

所以MySQL意外當機重啟也沒關係。只要在重啟時解析redo log中的事務然後重放一遍。將Buffer Pool中的快取頁重做成髒頁。後續再在合適的時機將該髒頁刷入磁碟即可。

於是對於業務方來說，everything is ok！

redo log側重於重做！redo log中記錄的是物理層面的資料頁、偏移量。應對的問題是：MySQL異常當機後，如何將沒來得及提交的事物資料重做出來。

而後面文章中和大家分享的bin log中記錄了你對XXX表條件為XXX處的資料作了什麼修改，這是些都是邏輯上的概念。

三、redo log block

首先你得知道，redo並不是一條條直接寫入磁碟中去的！

在MySQL的設定中，redolog是按塊，一塊一塊的寫入到磁碟中去的。

你可以類比一下資料是按頁為單位來組織的，就更容易理解為啥redo log 要按照block來組織redo。

本質上就是兩個字：優化

log block長成下面這這樣：分成Header、Body、Trailer三部分總共512位元組。而且是覆蓋寫入。

我粗略解讀一下這幅腦圖。

首先既然MySQL會寫redo log，說明你的sql會對快取頁造成修改，也就意味著會走MySQL設定的事物那一套機制。既然是MySQL事物，大概率就是一組增、刪、改。如果每個增、刪、改都會有一個對應的redo log的話，那也就是說你的事物會產生好多redolog。這些redo會先被持續不斷的寫入到log block中，同一個事物產生的redo log會被標記為一個redo log group。

四、redo log buffer

瞭解redo log block之後，白日夢還要跟你介紹一下 redo log buffer。

這個redo log buffer 中會劃分出多個rodo log block。redo log buffer 佔用一塊連續的記憶體空間，預設大小16MB。且MySQL允許我們通過引數innodb_log_buffer_size動態的調整它。增大它的大小可以讓MySQL處理大事物是不必寫入磁碟。進而提升寫IO效能。

引入rodo log buffer之後，就可以勾勒出這樣一副腦圖。

如圖，產生的redo log 先寫入redo log block。然後redo log block其實就在redo log buffer 中。

看到這裡不知道你有沒有想到這樣一個問題：redo log buffer再怎麼神奇畢竟也是僅僅在記憶體中，此時萬一MySQL當機了怎麼辦？redolog-buffer中的資料丟失了怎麼辦？畢竟沒有寫到磁碟上，MySQL重啟後100%沒辦法將其恢復出來。

其實你並不用擔心這種情況！

因為在MySQL的設定中，當你要Commit事務時，redolog才會持久化進磁碟，既然你沒有commit，碰巧MySQL又當機了。那讓MySQL正常重啟就好了啊，反正你沒有commit，MySQL也也沒有必要幫你恢復什麼。

那 redo log buffer 何時寫入磁碟呢？

事物提交時把它對應的那些redo log寫入到磁碟中去（這個動作可由相關引數控制，下文會說）
當redo log buffer 使用量達到了引數innndb_log_buffer_size的一半時，會觸發落盤。
會有一個後臺執行緒，每隔1秒就會將redo log block重新整理到磁碟檔案中去。
MySQL關閉時也會將其落盤。

五、redo log的刷盤時機

承接上面描述的場景：事務提交時，率先將redo log持久化進磁碟。

那你如何控制MySQL，讓MySQL在Commit事務時率先將redo log持久化呢？

MySQL提供了引數innodb_flush_log_at_trx_commit

該引數有幾個選項：0、1、2

想要保證ACID四大特性推薦設定為1：表示當你commit時，MySQL必須將rodolog-buffer中的資料重新整理進磁碟中。確保只要commit是成功的，磁碟上就得有對應的rodolog日誌。這也是最安全的情況。
設定為0：每秒寫一次日誌並將其重新整理到磁碟。
設定為2：表示當你commit時，將redolog-buffer中的資料重新整理進OS Cache中，然後依託於作業系統每秒重新整理一次的機制將資料同步到磁碟中，也存在丟失的風險。