來(lái)源：https://blog.csdn.net/demonson/article/details/104369733

innodb事務(wù)日志包括redo log和undo log。redo log是重做日志，提供前滾操作，undo log是回滾日志，提供回滾操作。

undo log不是redo log的逆向過(guò)程，其實(shí)它們都算是用來(lái)恢復(fù)的日志：

1.redo log通常是物理日志，記錄的是數(shù)據(jù)頁(yè)的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來(lái)恢復(fù)提交后的物理數(shù)據(jù)頁(yè)(恢復(fù)數(shù)據(jù)頁(yè)，且只能恢復(fù)到最后一次提交的位置)。

2.undo用來(lái)回滾行記錄到某個(gè)版本。undo log一般是邏輯日志，根據(jù)每行記錄進(jìn)行記錄。

1.redo log

1.1 redo log和二進(jìn)制日志的區(qū)別

1. 二進(jìn)制日志是在 存儲(chǔ)引擎的上層產(chǎn)生的，不管是什么存儲(chǔ)引擎，對(duì)數(shù)據(jù)庫(kù)進(jìn)行了修改都會(huì)產(chǎn)生二進(jìn)制日志。而redo log是innodb層產(chǎn)生的，只記錄該存儲(chǔ)引擎中表的修改。 并且二進(jìn)制日志先于redo log被記錄。具體的見(jiàn)后文group commit小結(jié)。
2. 二進(jìn)制日志記錄操作的方法是邏輯性的語(yǔ)句。即便它是基于行格式的記錄方式，其本質(zhì)也還是邏輯的SQL設(shè)置，如該行記錄的每列的值是多少。而redo log是在物理格式上的日志，它記錄的是數(shù)據(jù)庫(kù)中每個(gè)頁(yè)的修改。
3. 二進(jìn)制日志只在每次事務(wù)提交的時(shí)候一次性寫(xiě)入緩存中的日志"文件"(對(duì)于非事務(wù)表的操作，則是每次執(zhí)行語(yǔ)句成功后就直接寫(xiě)入)。而redo log在數(shù)據(jù)準(zhǔn)備修改前寫(xiě)入緩存中的redo log中，然后才對(duì)緩存中的數(shù)據(jù)執(zhí)行修改操作；而且保證在發(fā)出事務(wù)提交指令時(shí)，先向緩存中的redo log寫(xiě)入日志，寫(xiě)入完成后才執(zhí)行提交動(dòng)作。
4. 因?yàn)槎M(jìn)制日志只在提交的時(shí)候一次性寫(xiě)入，所以二進(jìn)制日志中的記錄方式和提交順序有關(guān)，且一次提交對(duì)應(yīng)一次記錄。而redo log中是記錄的物理頁(yè)的修改，redo log文件中同一個(gè)事務(wù)可能多次記錄，最后一個(gè)提交的事務(wù)記錄會(huì)覆蓋所有未提交的事務(wù)記錄。例如事務(wù)T1，可能在redo log中記錄了 T1-1,T1-2,T1-3，T1*?共4個(gè)操作，其中 T1*?表示最后提交時(shí)的日志記錄，所以對(duì)應(yīng)的數(shù)據(jù)頁(yè)最終狀態(tài)是 T1*?對(duì)應(yīng)的操作結(jié)果。而且redo log是并發(fā)寫(xiě)入的，不同事務(wù)之間的不同版本的記錄會(huì)穿插寫(xiě)入到redo log文件中，例如可能redo log的記錄方式如下：T1-1,T1-2,T2-1,T2-2,T2*,T1-3,T1*?。
5. 事務(wù)日志記錄的是物理頁(yè)的情況，它具有冪等性，因此記錄日志的方式極其簡(jiǎn)練。冪等性的意思是多次操作前后狀態(tài)是一樣的，例如新插入一行后又刪除該行，前后狀態(tài)沒(méi)有變化。而二進(jìn)制日志記錄的是所有影響數(shù)據(jù)的操作，記錄的內(nèi)容較多。例如插入一行記錄一次，刪除該行又記錄一次。
   
   

1.2 redo log的基本概念

在此處需要注意一點(diǎn)，一般所說(shuō)的log file并不是磁盤(pán)上的物理日志文件，而是操作系統(tǒng)緩存中的log file，官方手冊(cè)上的意思也是如此(例如：With a value of 2, the contents of the InnoDB log buffer are written to the log file?after each transaction commit and? the log file is flushed to disk approximately once per second)。

但說(shuō)實(shí)話，這不太好理解，既然都稱為file了，應(yīng)該已經(jīng)屬于物理文件了。所以在本文后續(xù)內(nèi)容中都以os buffer或者file system buffer來(lái)表示官方手冊(cè)中所說(shuō)的Log file，然后log file則表示磁盤(pán)上的物理日志文件，即log file on disk。

另外，之所以要經(jīng)過(guò)一層os buffer，是因?yàn)閛pen日志文件的時(shí)候，open沒(méi)有使用O_DIRECT標(biāo)志位，該標(biāo)志位意味著繞過(guò)操作系統(tǒng)層的os buffer，IO直寫(xiě)到底層存儲(chǔ)設(shè)備。不使用該標(biāo)志位意味著將日志進(jìn)行緩沖，緩沖到了一定容量，或者顯式fsync()才會(huì)將緩沖中的刷到存儲(chǔ)設(shè)備。使用該標(biāo)志位意味著每次都要發(fā)起系統(tǒng)調(diào)用。比如寫(xiě)abcde，不使用o_direct將只發(fā)起一次系統(tǒng)調(diào)用，使用o_object將發(fā)起5次系統(tǒng)調(diào)用。

• 當(dāng)設(shè)置為1的時(shí)候，事務(wù)每次提交都會(huì)將log buffer中的日志寫(xiě)入os buffer并調(diào)用fsync()刷到log file on disk中。這種方式即使系統(tǒng)崩潰也不會(huì)丟失任何數(shù)據(jù)，但是因?yàn)槊看翁峤欢紝?xiě)入磁盤(pán)，IO的性能較差。
• 當(dāng)設(shè)置為0的時(shí)候，事務(wù)提交時(shí)不會(huì)將log buffer中日志寫(xiě)入到os buffer，而是每秒寫(xiě)入os buffer并調(diào)用fsync()寫(xiě)入到log file on disk中。也就是說(shuō)設(shè)置為0時(shí)是(大約)每秒刷新寫(xiě)入到磁盤(pán)中的，當(dāng)系統(tǒng)崩潰，會(huì)丟失1秒鐘的數(shù)據(jù)。
• 當(dāng)設(shè)置為2的時(shí)候，每次提交都僅寫(xiě)入到os buffer，然后是每秒調(diào)用fsync()將os buffer中的日志寫(xiě)入到log file on disk。

• 如果啟用了二進(jìn)制日志，則設(shè)置sync_binlog=1，即每提交一次事務(wù)同步寫(xiě)到磁盤(pán)中。
• 總是設(shè)置innodb_flush_log_at_trx_commit=1，即每提交一次事務(wù)都寫(xiě)到磁盤(pán)中。

   

    #創(chuàng)建測(cè)試表
    

   

    

     drop table if exists test_flush_log;
     create table test_flush_log(id int,name char(50))engine=innodb;
    

   

    
#創(chuàng)建插入指定行數(shù)的記錄到測(cè)試表中的存儲(chǔ)過(guò)程
    

   

drop procedure if exists proc;delimiter $$create procedure proc(i int)begin declare s int default 1; declare c char(50) default repeat('a',50); while s<=i do start transaction; insert into test_flush_log values(null,c); commit; set s=s+1; end while;end$$delimiter ;

當(dāng)前環(huán)境下， innodb_flush_log_at_trx_commit 的值為1，即每次提交都刷日志到磁盤(pán)。測(cè)試此時(shí)插入10W條記錄的時(shí)間。

mysql> call proc(100000);Query OK, 0 rows affected (15.48 sec)

    

     mysql> set @@global.innodb_flush_log_at_trx_commit=2; 
     mysql>?truncate?test_flush_log;
     mysql> call proc(100000);
     Query OK, 0 rows affected (3.41 sec)
    

    

     mysql> set @@global.innodb_flush_log_at_trx_commit=0;
     mysql> truncate test_flush_log;
     

     mysql> call proc(100000);
     Query OK, 0 rows affected (2.10 sec)
    

    

     drop procedure if exists proc;
     delimiter $$
     create procedure proc(i int)
     begin
      declare s int default 1;
      declare c char(50) default repeat('a',50);
      start transaction;
      while s<=i DO
      insert into test_flush_log values(null,c);
      set s=s+1;
      end while;
      commit;
     end$$
     delimiter ;
    

    

     mysql> set @@global.innodb_flush_log_at_trx_commit=1;
     mysql>?truncate?test_flush_log;
    

    

     mysql> call proc(1000000);
     Query OK, 0 rows affected (11.26 sec)
    

1.3 日志塊(log block)

• log_block_hdr_no：(4字節(jié))該日志塊在redo log buffer中的位置ID。
• log_block_hdr_data_len：(2字節(jié))該log block中已記錄的log大小。寫(xiě)滿該log block時(shí)為0x200，表示512字節(jié)。
• log_block_first_rec_group：(2字節(jié))該log block中第一個(gè)log的開(kāi)始偏移位置。
• lock_block_checkpoint_no：(4字節(jié))寫(xiě)入檢查點(diǎn)信息的位置。

1.4 log group和redo log file

   

    mysql> show global variables like "innodb_log%";
    
+-----------------------------+----------+
    
| Variable_name               | Value    |
    
+-----------------------------+----------+
    
| innodb_log_buffer_size      | 8388608  |
    
| innodb_log_compressed_pages | ON       |
    
| innodb_log_file_size        | 50331648 |
    
| innodb_log_files_in_group   | 2        |
    
| innodb_log_group_home_dir   | ./       |
    
+-----------------------------+----------+
    

    
[root@xuexi data]# ll /mydata/data/ib*
    
-rw-rw---- 1 mysql mysql 79691776 Mar 30 23:12 /mydata/data/ibdata1
    
-rw-rw---- 1 mysql mysql 50331648 Mar 30 23:12 /mydata/data/ib_logfile0
    
-rw-rw---- 1 mysql mysql 50331648 Mar 30 23:12 /mydata/data/ib_logfile1
   

1.5 redo log的格式

• redo_log_type：占用1個(gè)字節(jié)，表示redo log的日志類型。
• space：表示表空間的ID，采用壓縮的方式后，占用的空間可能小于4字節(jié)。
• page_no：表示頁(yè)的偏移量，同樣是壓縮過(guò)的。
• redo_log_body表示每個(gè)重做日志的數(shù)據(jù)部分，恢復(fù)時(shí)會(huì)調(diào)用相應(yīng)的函數(shù)進(jìn)行解析。例如insert語(yǔ)句和delete語(yǔ)句寫(xiě)入redo log的內(nèi)容是不一樣的。

1.6 日志刷盤(pán)的規(guī)則

1.7 數(shù)據(jù)頁(yè)刷盤(pán)的規(guī)則及checkpoint

• sharp checkpoint：在重用redo log文件(例如切換日志文件)的時(shí)候，將所有已記錄到redo log中對(duì)應(yīng)的臟數(shù)據(jù)刷到磁盤(pán)。
• fuzzy checkpoint：一次只刷一小部分的日志到磁盤(pán)，而非將所有臟日志刷盤(pán)。有以下幾種情況會(huì)觸發(fā)該檢查點(diǎn)：
• master thread checkpoint：由master線程控制， 每秒或每10秒刷入一定比例的臟頁(yè)到磁盤(pán)。
• flush_lru_list checkpoint：從MySQL5.6開(kāi)始可通過(guò) innodb_page_cleaners 變量指定專門(mén)負(fù)責(zé)臟頁(yè)刷盤(pán)的page cleaner線程的個(gè)數(shù)，該線程的目的是為了保證lru列表有可用的空閑頁(yè)。
• async/sync flush checkpoint：同步刷盤(pán)還是異步刷盤(pán)。例如還有非常多的臟頁(yè)沒(méi)刷到磁盤(pán)(非常多是多少，有比例控制)，這時(shí)候會(huì)選擇同步刷到磁盤(pán)，但這很少出現(xiàn)；如果臟頁(yè)不是很多，可以選擇異步刷到磁盤(pán)，如果臟頁(yè)很少，可以暫時(shí)不刷臟頁(yè)到磁盤(pán)
• dirty page too much checkpoint：臟頁(yè)太多時(shí)強(qiáng)制觸發(fā)檢查點(diǎn)，目的是為了保證緩存有足夠的空閑空間。too much的比例由變量 innodb_max_dirty_pages_pct 控制，MySQL 5.6默認(rèn)的值為75，即當(dāng)臟頁(yè)占緩沖池的百分之75后，就強(qiáng)制刷一部分臟頁(yè)到磁盤(pán)。

MySQL停止時(shí)是否將臟數(shù)據(jù)和臟日志刷入磁盤(pán)，由變量innodb_fast_shutdown={ 0|1|2 }控制，默認(rèn)值為1，即停止時(shí)只做一部分purge，忽略大多數(shù)flush操作(但至少會(huì)刷日志)，在下次啟動(dòng)的時(shí)候再flush剩余的內(nèi)容，實(shí)現(xiàn)fast shutdown。

1.8 LSN超詳細(xì)分析

    

     mysql> show engine innodb stauts
     ---
     LOG
     ---
     Log sequence number 2225502463
     Log flushed up to 2225502463
     Pages flushed up to 2225502463
     Last checkpoint at 2225502463
     0 pending log writes, 0 pending chkp writes
     3201299 log i/o's done, 0.00 log i/o's/second
    

• log sequence number就是當(dāng)前的redo log(in buffer)中的lsn；
• log flushed up to是刷到redo log file on disk中的lsn；
• pages flushed up to是已經(jīng)刷到磁盤(pán)數(shù)據(jù)頁(yè)上的LSN；
• last checkpoint at是上一次檢查點(diǎn)所在位置的LSN。

   

    log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at
   

    

     log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at
    

    

     log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at
    

    

     log sequence number = log flushed up to > pages flushed up to = last checkpoint at
    

1.9 innodb的恢復(fù)行為

1.10 和redo log有關(guān)的幾個(gè)變量

• innodb_flush_log_at_trx_commit={0|1|2} # 指定何時(shí)將事務(wù)日志刷到磁盤(pán)，默認(rèn)為1。
• 0表示每秒將"log buffer"同步到"os buffer"且從"os buffer"刷到磁盤(pán)日志文件中。
• 1表示每事務(wù)提交都將"log buffer"同步到"os buffer"且從"os buffer"刷到磁盤(pán)日志文件中。
• 2表示每事務(wù)提交都將"log buffer"同步到"os buffer"但每秒才從"os buffer"刷到磁盤(pán)日志文件中。
• innodb_log_buffer_size：# log buffer的大小，默認(rèn)8M
• innodb_log_file_size：#事務(wù)日志的大小，默認(rèn)5M
• innodb_log_files_group =2：# 事務(wù)日志組中的事務(wù)日志文件個(gè)數(shù)，默認(rèn)2個(gè)
• innodb_log_group_home_dir =./：# 事務(wù)日志組路徑，當(dāng)前目錄表示數(shù)據(jù)目錄
• innodb_mirrored_log_groups =1：# 指定事務(wù)日志組的鏡像組個(gè)數(shù)，但鏡像功能好像是強(qiáng)制關(guān)閉的，所以只有一個(gè)log group。在MySQL5.7中該變量已經(jīng)移除。

2.undo log

2.1 基本概念

2.2 undo log的存儲(chǔ)方式

    

     [root@xuexi data]# ll /mydata/data/ib*
     -rw-rw---- 1 mysql mysql 79691776 Mar 31 01:42 /mydata/data/ibdata1
     -rw-rw---- 1 mysql mysql 50331648 Mar 31 01:42 /mydata/data/ib_logfile0
     -rw-rw---- 1 mysql mysql 50331648 Mar 31 01:42 /mydata/data/ib_logfile1
    

    

     2017-03-31 13:16:00 7f665bfab720 InnoDB: Expected to open 3 undo tablespaces but was able
     2017-03-31 13:16:00 7f665bfab720 InnoDB: to find only 0 undo tablespaces.
     2017-03-31 13:16:00 7f665bfab720 InnoDB: Set the innodb_undo_tablespaces parameter to the
     2017-03-31 13:16:00 7f665bfab720 InnoDB: correct value and retry. Suggested value is 0
    

2.3 和undo log相關(guān)的變量

    

      mysql> show variables like "%undo%";
     +-------------------------+-------+
     | Variable_name | Value |
     +-------------------------+-------+
     | innodb_undo_directory | . |
     | innodb_undo_logs | 128 |
     | innodb_undo_tablespaces | 0 |
     +-------------------------+-------+
    

2.4 delete/update操作的內(nèi)部機(jī)制

• delete操作實(shí)際上不會(huì)直接刪除，而是將delete對(duì)象打上delete flag，標(biāo)記為刪除，最終的刪除操作是purge線程完成的。
• update分為兩種情況：update的列是否是主鍵列。
• 如果不是主鍵列，在undo log中直接反向記錄是如何update的。即update是直接進(jìn)行的。
• 如果是主鍵列，update分兩部執(zhí)行：先刪除該行，再插入一行目標(biāo)行。

3.binlog和事務(wù)日志的先后順序及group commit

如果事務(wù)不是只讀事務(wù)，即涉及到了數(shù)據(jù)的修改，默認(rèn)情況下會(huì)在commit的時(shí)候調(diào)用fsync()將日志刷到磁盤(pán)，保證事務(wù)的持久性。

但是一次刷一個(gè)事務(wù)的日志性能較低，特別是事務(wù)集中在某一時(shí)刻時(shí)事務(wù)量非常大的時(shí)候。innodb提供了group commit功能，可以將多個(gè)事務(wù)的事務(wù)日志通過(guò)一次fsync()刷到磁盤(pán)中。

因?yàn)槭聞?wù)在提交的時(shí)候不僅會(huì)記錄事務(wù)日志，還會(huì)記錄二進(jìn)制日志，但是它們誰(shuí)先記錄呢？二進(jìn)制日志是MySQL的上層日志，先于存儲(chǔ)引擎的事務(wù)日志被寫(xiě)入。

在MySQL5.6以前，當(dāng)事務(wù)提交(即發(fā)出commit指令)后，MySQL接收到該信號(hào)進(jìn)入commit prepare階段；進(jìn)入prepare階段后，立即寫(xiě)內(nèi)存中的二進(jìn)制日志，寫(xiě)完內(nèi)存中的二進(jìn)制日志后就相當(dāng)于確定了commit操作；然后開(kāi)始寫(xiě)內(nèi)存中的事務(wù)日志；最后將二進(jìn)制日志和事務(wù)日志刷盤(pán)，它們?nèi)绾嗡⒈P(pán)，分別由變量 sync_binlog 和 innodb_flush_log_at_trx_commit 控制。

但因?yàn)橐ＷC二進(jìn)制日志和事務(wù)日志的一致性，在提交后的prepare階段會(huì)啟用一個(gè)prepare_commit_mutex鎖來(lái)保證它們的順序性和一致性。但這樣會(huì)導(dǎo)致開(kāi)啟二進(jìn)制日志后group commmit失效，特別是在主從復(fù)制結(jié)構(gòu)中，幾乎都會(huì)開(kāi)啟二進(jìn)制日志。

在MySQL5.6中進(jìn)行了改進(jìn)。提交事務(wù)時(shí)，在存儲(chǔ)引擎層的上一層結(jié)構(gòu)中會(huì)將事務(wù)按序放入一個(gè)隊(duì)列，隊(duì)列中的第一個(gè)事務(wù)稱為leader，其他事務(wù)稱為follower，leader控制著follower的行為。雖然順序還是一樣先刷二進(jìn)制，再刷事務(wù)日志，但是機(jī)制完全改變了：刪除了原來(lái)的prepare_commit_mutex行為，也能保證即使開(kāi)啟了二進(jìn)制日志，group commit也是有效的。

MySQL5.6中分為3個(gè)步驟：flush階段、sync階段、commit階段。

• flush階段：向內(nèi)存中寫(xiě)入每個(gè)事務(wù)的二進(jìn)制日志。
• sync階段：將內(nèi)存中的二進(jìn)制日志刷盤(pán)。若隊(duì)列中有多個(gè)事務(wù)，那么僅一次fsync操作就完成了二進(jìn)制日志的刷盤(pán)操作。這在MySQL5.6中稱為BLGC(binary log group commit)。
• commit階段：leader根據(jù)順序調(diào)用存儲(chǔ)引擎層事務(wù)的提交，由于innodb本就支持group commit，所以解決了因?yàn)殒i prepare_commit_mutex 而導(dǎo)致的group commit失效問(wèn)題。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝