MySQL系列之redo log、undo log和binlog詳解
redo log保證事務(wù)的持久性，undo log用來幫助事務(wù)回滾及MVCC的功能。
InnoDB存儲引擎體系結(jié)構(gòu)
Write Ahead Log策略
事務(wù)提交時，先寫重做日志再修改頁；當(dāng)由于發(fā)生宕機而導(dǎo)致數(shù)據(jù)丟失時，就可以通過重做日志來完成數(shù)據(jù)的恢復(fù)。
InnoDB首先將重做日志信息先放到重做日志緩存 按一定頻率刷新到重做日志文件重做日志文件： 在默認情況，InnoDB存儲引擎的數(shù)據(jù)目錄下會有兩個名為ib_logfile1和ib_logfile2的文件。每個InnoDB存儲引擎至少有1個重做日志文件組(group)，每個文件組下至少有2個重做日志文件。
下面圖一，很好說明重做日志組以循環(huán)寫入方式運行，InnoDB存儲引擎先寫ib_logfile1，當(dāng)達到文件最后時，會切換至重做日志文件ib_logfile2.
而圖2，增加一個OS Buffer，有助于理解fsync過程。
關(guān)于log group，稱為重做日志組，是一個邏輯上的概念。InnoDB存儲引擎實際只有一個log group。
log group中第一個redo log file，其前2KB部分保存4個512字節(jié)大小塊：
重做日志緩沖刷新到磁盤
下面三種情況刷新：
Master Thread每一秒將重做日志緩沖刷新到重做日志文件 每個事務(wù)提交時會將重做日志緩沖刷新到重做日志文件 當(dāng)重做日志緩沖池剩余空間小于1/2時，重做日志刷新到重做日志文件補充上述三種情況第二種，觸發(fā)寫磁盤過程由參數(shù)innodb_flush_log_at_trx_commit控制，表示提交(commit)操作時，處理重做日志的方式。
參數(shù)innodb_flush_log_at_trx_commit有效值有0、1、2
0表示當(dāng)提交事務(wù)時，并不將事務(wù)的重做日志寫入磁盤上日志文件，而是等待主線程每秒刷新。 1表示在執(zhí)行commit時將重做日志緩沖同步寫到磁盤，即伴有fsync的調(diào)用 2表示將重做日志異步寫到磁盤，即寫到文件系統(tǒng)的緩存中。不保證commit時肯定會寫入重做日志文件。0，當(dāng)數(shù)據(jù)庫發(fā)生宕機時，部分日志未刷新到磁盤，因此會丟失最后一段時間的事務(wù)。2，當(dāng)操作系統(tǒng)宕機時，重啟數(shù)據(jù)庫后會丟失未從文件系統(tǒng)緩存刷新到重做日志文件那部分事務(wù)。
下圖有助于理解
在InnoDB存儲引擎中，重做日志都是以512字節(jié)進行存儲的。意味著重做日志緩存、重做日志文件都是以塊(block)的方式進行保存的，每塊512字節(jié)。
重做日志頭12字節(jié)，重做日志尾8字節(jié)，故每個重做日志塊實際可以存儲492字節(jié)。
redo log是基于頁的格式來記錄的。默認情況下，innodb的頁大小是16KB(由 innodb_page_size變量控制)，一個頁內(nèi)可以存放非常多的log block(每個512字節(jié))，而log block中記錄的又是數(shù)據(jù)頁的變化。
log body的格式分為4部分：
redo_log_type：占用1個字節(jié)，表示redo log的日志類型。 space：表示表空間的ID，采用壓縮的方式后，占用的空間可能小于4字節(jié)。 page_no：表示頁的偏移量，同樣是壓縮過的。 redo_log_body表示每個重做日志的數(shù)據(jù)部分，恢復(fù)時會調(diào)用相應(yīng)的函數(shù)進行解析。例如insert語句和delete語句寫入redo log的內(nèi)容是不一樣的。
如下圖，分別是insert和delete大致的記錄方式。
下面LSN(Log Sequence Number)代表checkpoint，當(dāng)數(shù)據(jù)庫在LSN為10000時發(fā)生宕機，恢復(fù)操作僅恢復(fù)LSN10000-LSN13000范圍內(nèi)日志
undo log的作用
undo是邏輯日志，只是將數(shù)據(jù)庫邏輯地恢復(fù)到原來的樣子；所有修改都被邏輯地取消了，但是數(shù)據(jù)結(jié)構(gòu)和頁本身在回滾之后可能不大相同。
undo log有兩個作用：提供回滾和多個行版本控制(MVCC)。
InnoDB存儲引擎回滾時，對于每個INSERT，會完成一個DELETE；對于每個DELETE，會執(zhí)行一個INSERT；對于每個UPDATE，會執(zhí)行一個相反的UPDATE，將修改前的行放回去。
MVCC： 當(dāng)用戶讀取一行記錄時，若該記錄已經(jīng)被其他事務(wù)占用，當(dāng)前事務(wù)可以通過undo讀取之前的行版本信息，以此實現(xiàn)非鎖定讀取。
undo log的存儲方式innodb存儲引擎對undo的管理采用段的方式。rollback segment稱為回滾段，每個回滾段中有1024個undo log segment。
在以前老版本，只支持1個rollback segment，這樣就只能記錄1024個undo log segment。后來MySQL5.5可以支持128個rollback segment，即支持128*1024個undo操作，還可以通過變量 innodb_undo_logs (5.6版本以前該變量是 innodb_rollback_segments )自定義多少個rollback segment，默認值為128。
undo log默認存放在共享表空間中。
事務(wù)提交undo log處理過程
當(dāng)事務(wù)提交時，InnoDB存儲引擎會做以下兩件事：
將undo log放入一個列表中，以供之后的purge使用，是否可以最終刪除undo log及所在頁由purge線程來判斷 判斷undo log 所在的頁是否可以重用，若可以，分配給下個事務(wù)使用當(dāng)事務(wù)提交時，首先將undo log放入鏈表中，然后判斷undo頁的使用空間是否小于3/4，若是，則表示該undo頁可以被重用，之后新的undo log記錄在當(dāng)前undo log的后面
undo log分為：
insert undo log update undo log因為事務(wù)隔離性，insert undo log對其他事務(wù)不可見，所以該undo log可以在事務(wù)提交后直接刪除，不需要進行purge操作。
update undo log記錄的是對delete和update操作產(chǎn)生的undo log。該undo log可能需要提供MVCC機制，因此不能提交時就進行刪除
update分為兩種情況：
date的列如果不是主鍵列，在undo log中直接反向記錄是如何update的。即update是直接進行的。 update主鍵的操作可以分為兩步： 首先將原主鍵記錄標(biāo)記為已刪除，因此需要產(chǎn)生一個類型為TRX_UNDO_DEL_MARK_REC的undo log 之后插入一條新的記錄，產(chǎn)生一個類型為TRX_UNDO_INSERT_MARK_REC的undo log
InnoDB purge時，會先從history列表找undo log，然后再從undo page中找undo log；可以避免大量隨機讀取操作，從而提高purge效率。
MVCC其實就是在每一行記錄后面增加兩個隱藏列，記錄創(chuàng)建版本號和刪除版本號，而每一個事務(wù)在啟動的時候，都有一個唯一的遞增的版本號。
MVCC只在REPEATABLE READ 和READ COMMITTED兩個隔離級別下工作。讀未提交不存在版本問題，序列化則對所有讀取行加鎖。
示例：
插入操作：記錄的創(chuàng)建版本號就是事務(wù)版本號
如插入一條記錄，事務(wù)id假設(shè)是1，則創(chuàng)建版本號也是1
id name create version delete version 1 test 1
更新操作：先標(biāo)記舊版本號為已刪除，版本號就是當(dāng)前版本號，再插入一條新的記錄
如事務(wù)2把name字段更新update table set name = ’new test’ where id = 1;
原來的記錄被標(biāo)記刪除，刪除版本號為2，并插入新記錄，創(chuàng)建版本號為2
id name create version delete version 1 test 1 2 1 new test 2刪除操作：把事務(wù)版本作為刪除版本號
如事務(wù)3把記錄刪除delete from table where id = 1;
id name create version delete version 1 test 2 3 查詢操作需滿足以下兩個條件的記錄才能被事務(wù)查詢出來：
InnoDB只查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行 行的刪除版本要么未定義，要么大于當(dāng)前版本號，這可以確保事務(wù)讀取到的行，在事務(wù)未開始之前未被刪除MVCC好處：減少鎖的爭用，提升性能
binlog二進制文件概念及作用
二進制文件(binary log)記錄了對MySQL數(shù)據(jù)庫執(zhí)行更改的所有操作(不包含SELECT、SHOW等，因為對數(shù)據(jù)沒有修改)
二進制文件主要幾種作用：
恢復(fù)：某些數(shù)據(jù)的恢復(fù)需要二進制日志 復(fù)制： 通過復(fù)制和執(zhí)行二進制日志使一臺遠程的MySQL(slave)與另一臺MySQL數(shù)據(jù)庫(master)進行實時同步 審計： 用戶可以通過二進制日志中信息來進行審計，判斷是否有對數(shù)據(jù)庫進行注入的攻擊二進制文件三個格式
MySQL 5.1開始引入binlog_format參數(shù)，該參數(shù)可設(shè)值有STATEMENT、ROW和MIX
STATEMENT： 二進制文件記錄的是日志的邏輯SQL語句 ROW：記錄表的行更改情況。如果設(shè)置了ROW模式，可以將InnoDB事務(wù)隔離級別設(shè)為READ_COMMITTED，以獲得更好的并發(fā)性 MIX：MySQL默認采用STATEMENT格式進行二進制文件的記錄，但在一些情況下會使用ROW，可能的情況有： 表的存儲引擎為NDB，這時對表DML操作都以ROW格式進行 使用了UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不確定函數(shù) 使用了INSERT DELAY語句 使用了用戶定義函數(shù) 使用了臨時表redo log和二進制文件區(qū)別(二進制文件用來進行POINT-IN-TIME(PIT))的恢復(fù)及主從復(fù)制環(huán)境的建立。
二進制文件會記錄所有與MySQL數(shù)據(jù)庫有關(guān)的日志記錄，包括InnoDB、MyISAM等其他存儲引擎的日志。而InnoDB存儲引擎的重做日志只記錄有關(guān)該存儲引擎本身的事務(wù)日志。 記錄的內(nèi)容不同，無論用戶將二進制日志文件記錄的格式設(shè)為STATEMENT、ROW或MIXED，其記錄的都是關(guān)于一個事務(wù)的具體操作內(nèi)容，即該日志是邏輯日志。而InnoDB存儲引擎的重做日志文件記錄的是關(guān)于每個頁的更改的物理情況。 此外，寫入的時間頁不同，二進制日志文件僅再事務(wù)提交前進行提交，即只寫磁盤一次，不論這時該事務(wù)多大。而在事務(wù)進行的過程中，卻不斷有重做日志條目(reod entry)被寫入到重做日志文件中。
group commit
若事務(wù)為非只讀事務(wù)，則每次事務(wù)提交時需要進行一次fsync操作，以此保證重做日志都已經(jīng)寫入磁盤。但磁盤fsync性能有限，為提高磁盤fsync效率，當(dāng)前數(shù)據(jù)庫都提供group commit功能，即一次可以刷新確保多個事務(wù)日志被寫入文件。
對InnoDB group commit，進行兩階段操作：
修改內(nèi)存中事務(wù)對應(yīng)的信息，并且將日志寫入重做日志緩沖 調(diào)用fsync將確保日志都從重做日志緩沖寫入磁盤InnoDB1.2前，開啟二進制文件，group commit功能失效問題：
開啟二進制文件后，其步驟如下：1）當(dāng)事務(wù)提交時，InnoDB存儲引擎進行prepare操作2）MySQL數(shù)據(jù)庫上層寫入二進制文件3）InnoDB將日志寫入重做日志文件
a）修改內(nèi)存中事務(wù)對應(yīng)的信息，并將日志寫入重做日志緩沖b）調(diào)用fsync將確保日志都從重做日志緩沖寫入磁盤
其中在保證MySQL數(shù)據(jù)庫上層二進制文件的寫入順序，和InnoDB事務(wù)提交順序一致，MySQL內(nèi)部使用了prepare_commit_mutex鎖，從而步驟3）中a）步不可以在其他事務(wù)執(zhí)行步驟b）時進行，從而導(dǎo)致roup commit功能失效。
解決方案便是BLGC(Binary Log Group Commit)
MySQL 5.6 BLGC實現(xiàn)方式分為三個階段：
Flush階段：將每個事務(wù)的二進制文件寫入內(nèi)存 Sync階段：將內(nèi)存中的二進制刷新到磁盤，若隊列有多個事務(wù)，那么僅一次fsync操作就完成了二進制日志的寫入，這就是BLGC Commit階段：leader根據(jù)順序調(diào)用存儲引擎層事務(wù)提交，由于innodb本就支持group commit，所以解決了因為鎖 prepare_commit_mutex 而導(dǎo)致的group commit失效問題。
到此這篇關(guān)于MySQL系列之redo log、undo log和binlog詳解的文章就介紹到這了,更多相關(guān)mysql redo log、undo log和binlog內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！
相關(guān)文章：
1. SQL INSERT及批量的幾種方式總結(jié)2. SQL Server 2008服務(wù)器合并功能介紹3. MariaDB性能調(diào)優(yōu)工具mytop的使用詳解4. mysql中的utf8與utf8mb4存儲及區(qū)別5. MySQL中utf8mb4排序規(guī)則示例6. MySQL數(shù)據(jù)庫字符集修改中文UTF8(永久修改)7. SQL SERVER中一些常見性能問題的總結(jié)8. 從DBA到Oracle Applications DBA的轉(zhuǎn)變過程9. Row_number()函數(shù)用法小結(jié)10. SQLite3 命令行操作指南
網(wǎng)公網(wǎng)安備