【转】【MySQL】运行原理（四）：重做日志（redo log），回滚日志（undo log），二进制日志（binlog）
MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進制日志（binlog）、錯誤日志（errorlog）、慢查詢日志（slow query log）、一般查詢日志（general log），中繼日志（relay log）。
其中重做日志和回滾日志與事務操作息息相關，二進制日志也與事務操作有一定的關系，這三種日志，對理解MySQL中的事務操作有著重要的意義。這里簡單總結一下這三者具有一定相關性的日志。
1.重做日志（redo log）
MySQL 在更新數據時，為了減少磁盤的隨機 IO，因此并不會直接更新磁盤上的數據，而是先更新 Buffer Pool 中緩存頁的數據，等到合適的時間點，再將這個緩存頁持久化到磁盤。而 Buffer Pool 中所有緩存頁都是處于內存當中的，當 MySQL 宕機或者機器斷電，內存中的數據就會丟失，因此 MySQL 為了防止緩存頁中的數據在更新后出現數據丟失的現象，引入了 redo log 機制。
當進行增刪改操作時，MySQL 會在更新 Buffer Pool 中的緩存頁數據時，會記錄一條對應操作的 redo log 日志，這樣如果出現 MySQL 宕機或者斷電時，如果有緩存頁的數據還沒來得及刷入磁盤，那么當 MySQL 重新啟動時，可以根據 redo log 日志文件，進行數據重做，將數據恢復到宕機或者斷電前的狀態，保證了更新的數據不丟失，因此 redo log 又叫做重做日志。它的本質是保證事務提交后，更新的數據不丟失。——用它來實現事務的持久性。
1.1 作用
確保事務的持久性。防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的持久性這一特性。
1.2 內容
物理格式的日志，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。
1.3 物理文件
默認情況下，對應的物理文件位于數據庫的data目錄下的 ib_logfile1&ib_logfile2
- innodb_log_group_home_dir 指定日志文件組所在的路徑，默認./ ，表示在數據庫的數據目錄下。
- innodb_log_files_in_group 指定重做日志文件組中文件的數量，默認2
- 關于文件的大小和數量，由以下兩個參數配置
- innodb_log_file_size 重做日志文件的大小。
- innodb_mirrored_log_groups 指定了日志鏡像文件組的數量，默認1
1.3 產生時機
事務開始之后就產生redo log，redo log的落盤并不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入redo log文件中。
1.4 釋放時機
當對應事務的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。
1.6 寫盤時機
很重要一點，redo log是什么時候寫盤的？
前面說了是在事物開始之后逐步寫盤的。之所以說重做日志是在事務開始之后逐步寫入重做日志文件，而不一定是事務提交才寫入重做日志緩存，原因就是，重做日志有一個緩存區Innodb_log_buffer，默認大小為8M，Innodb存儲引擎先將重做日志寫入innodb_log_buffer中。
然后可以通過以下三種方式將innodb日志緩沖區的日志刷新到磁盤
由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于第一種方式，Innodb_log_buffer 到重做日志文件是 Master Thread 線程的定時任務。因此重做日志的寫盤，并不一定是隨著事務的提交才寫入重做日志文件的，而是隨著事務的開始，逐步開始的。
另外引用《MySQL技術內幕 Innodb 存儲引擎》上的原話：
即使某個事務還沒有提交，Innodb存儲引擎仍然每秒會將重做日志緩存刷新到重做日志文件。這一點是必須要知道的，因為這可以很好地解釋再大的事務的提交（commit）的時間也是很短暫的。
?
2.回滾日志（undo log）
數據庫事務四大特性中有一個是原子性，具體來說就是原子性是指對數據庫的一系列操作，要么全部成功，要么全部失敗，不可能出現部分成功的情況。
實際上，原子性底層就是通過undo log實現的。undo log主要記錄了數據的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對于每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發生錯誤時，就能回滾到事務之前的數據狀態
2.1 作用
記錄了事務發生之前的數據狀態（不包括select） ，如果修改數據時出現異常，可以用undo log來實現回滾操作（保持原子性）。同時可以提供多版本并發控制下的讀（MVCC），也即非鎖定讀。
2.2 內容
邏輯格式的日志，可以簡單認為就是執行過的事務中的sql語句。但又不完全是sql語句這么簡單，而是包括了執行的sql語句（增刪改）反向的信息，也就意味著
- delete對應著delete本身和其反向的insert
- update對應著update執行前后的版本的信息
- insert對應著delete和insert本身的信息
在執行undo的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同于redo log的。
2.3 物理文件
MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認的名稱是ibdata，位于數據文件目錄中。
MySQL5.6之后，undo表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成數據庫初始化后生效且不可改變undo log文件的個數。如果初始化數據庫之前沒有進行相關配置，那么就無法配置成獨立的表空間了。
關于MySQL5.7之后的獨立undo 表空間配置參數如下
- innodb_undo_directory = /data/undospace/ --undo獨立表空間的存放目錄
- innodb_undo_logs = 128 --回滾段為128KB
- innodb_undo_tablespaces = 4 --指定有4個undo log文件
如果undo使用的共享表空間，這個共享表空間中又不僅僅是存儲了undo的信息，共享表空間的默認為與MySQL的數據目錄下面，其屬性由參數 innodb_data_file_path 配置。
默認情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當數據庫中發生一些大的事務性操作的時候，要生成大量的undo信息，全部保存在共享表空間中的。因此共享表空間可能會變的很大，默認情況下，也就是 undo 日志使用共享表空間的時候，被“撐大”的共享表空間是不會也不能自動收縮的。
因此，mysql5.7之后的“獨立undo 表空間”的配置就顯得很有必要了。
2.4 產生時機
事務開始之前，將當前是的版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性
2.5 釋放時機
當事務提交之后，undo log并不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務在使用undo段中表的上一個事務之前的版本信息，決定是否可以清理undo log的日志空間。
2.6 undo log 和 redo log
undo是在事務開始之前保存的被修改數據的一個版本，產生undo日志的時候，同樣會伴隨類似于保護事務持久化機制的redo log的產生。
- Redo 記錄某?數據塊?被修改?后?的值，可以用來恢復未寫入 data file 的已成功事務更新的數據。-- 保證事務持久性
- Undo 記錄某?數據?被修改?前?的值，可以用來在事務失敗時進行 rollback；-- 保證事務原子性
比如某一時刻數據庫 DOWN 機了，有兩個事務，一個事務已經提交，另一個事務正在處理。數據庫重啟的時候就要根據日志進行前滾及回滾，把已提交事務的更改寫到數據文件，未提交事務的更改恢復到事務開始前的狀態。
- 當數據 crash-recovery 時，通過 redo log 將所有已經在存儲引擎內部提交的事務應用 redo log 恢復
- 所有已經 prepared 但是沒有 commit 的 transactions 將會應用 undo log 做 roll back
問題一：可不可以只用 undo 或只用 redo？
問題二：說了這么多，undo+redo 有什么示例嗎？
示例一：假設有A、B兩個數據，值分別為1,2?，F在要將A修改成3，B修改成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.事務提交示例二：update過程分析。一個更新操作的流程，這是一個簡化的過程（name原值是zhangsan）。
update user set name='penyuyan' where id=1; 1. 事務開始，從內存或磁盤取到這條數據，返回給Server 的執行器； 2. 執行器修改這一行數據的值為penyuyan； 3. 記錄 name=zhangsan 到 undo log； 4. 記錄 name=penyuyan 到 redo log； 5. 調用存儲引擎接口，在內存（Buffer Pool）中修改 name=zhangsan； 6. 事務提交3.二進制日志（binlog）
3.1 作用
3.2 內容
bin log有三種格式,分別為STATMENT、ROW、和MIXED。
- STATMENT：基于SQL語句的復制(statement-based-replication,SBR),所有涉及到數據修改的sql語句都會記錄到bin log中
- 優點 ：不需要記錄每一行的變化，減少bin log日質量，節約IO，所以性能最好.
- 缺點:可能會在某些情況下導致主從數據不一致，例如執行sysdate()、sleep;
- ROW：基于行變化的復制(row-based replication,RBR),不需要記錄每一條sql語句信息,僅需要記錄哪一條數據被修改了.
- 優點：不會出現某些情況下的存儲過程、函數、觸發器調用無法被正確復制和回復的情況.
- 缺點：日志數量會增多,尤其是是在執行alter table的時候日志會暴漲
- MIXED：顧名思義就是以上兩種的混合使用模式(mixed-based replication,MBR),一般的復制使用STATEMENT，而對于STATEMENT無法復制的則使用ROW模式。
因此可以基于binlog做到類似于oracle的閃回功能，其實都是依賴于binlog中的日志記錄。
3.3 物理文件
配置文件的路徑為log_bin_basename，binlog日志文件按照指定大小，當日志文件達到指定的最大的大小之后，進行滾動更新，生成新的日志文件。
對于每個binlog日志文件，通過一個統一的index文件來組織。
3.4 產生時機
事務提交的時候，一次性將事務中的sql語句（一個事物可能對應多個sql語句）按照一定的格式記錄到binlog中。
這里與redo log很明顯的差異就是redo log并不一定是在事務提交的時候刷新到磁盤，redo log是在事務開始之后就開始逐步寫入磁盤。
因此對于事務的提交，即便是較大的事務，提交（commit）都是很快的，但是在開啟了bin_log的情況下，對于較大事務的提交，可能會變得比較慢一些。這是因為binlog是在事務提交的時候一次性寫入的造成的，這些可以通過測試驗證。
3.5 釋放時機
binlog的默認是保持時間由參數expire_logs_days配置，也就是說對于非活動的日志文件，在生成時間超過expire_logs_days配置的天數之后，會被自動刪除。
3.6 redo/undo log 和 binlog
二進制日志的作用之一是還原數據庫的，這與redo/undo log很類似，但兩者區別還是挺多的，大致如下：
- 層次不同
- redo/undo 是 innodb 引擎層維護的，是保證事務的持久性的，是事務層面的。
- binlog 是 mysql server 層維護的，跟采用何種引擎沒有關系，記錄的是所有引擎的更新操作的日志記錄。雖然都有還原的意思，但是其保護數據的層次是不一樣的。
- 記錄內容不同
- redo/undo 記錄的是 每個頁/每個數據 的修改情況，屬于物理日志+邏輯日志結合的方式（redo log 是物理日志，undo log 是邏輯日志）。
- binlog 記錄的都是事務操作內容，binlog 有三種模式：Statement（基于 SQL 語句的復制）、Row（基于行的復制） 以及 Mixed（混合模式）。不管采用的是什么模式，當然格式是二進制的。
- 記錄時機不同
- redo/undo 在 事務執行過程中會不斷的寫入。
- binlog 是在事務最終提交前寫入的。binlog 什么時候刷新到磁盤跟參數 sync_binlog 相關。
關于事務提交時，redo log 和 binlog的寫入順序，為了保證主從復制時候的主從一致（當然也包括使用binlog進行基于時間點還原的情況），是要嚴格一致的，
MySQL通過兩階段提交過程來完成事務的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個日志都提交成功（刷入磁盤），事務才算真正的完成。參考鏈接…
總結
以上是生活随笔為你收集整理的【转】【MySQL】运行原理（四）：重做日志（redo log），回滚日志（undo log），二进制日志（binlog）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《艾尔登法环》1.05版本上线 铃珠可在
- 下一篇： 【转】2.2【MySQL】运行原理（二）