MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進(jìn)制日志（binlog）、錯(cuò)誤日志（errorlog）、慢查詢(xún)?nèi)罩?#xff08;slow query log）、一般查詢(xún)?nèi)罩?#xff08;general log），中繼日志（relay log）。

其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進(jìn)制日志也與事務(wù)操作有一定的關(guān)系，這三種日志，對(duì)理解MySQL中的事務(wù)操作有著重要的意義。這里簡(jiǎn)單總結(jié)一下這三者具有一定相關(guān)性的日志。

1.重做日志（redo log）

MySQL 在更新數(shù)據(jù)時(shí)，為了減少磁盤(pán)的隨機(jī) IO，因此并不會(huì)直接更新磁盤(pán)上的數(shù)據(jù)，而是先更新 Buffer Pool 中緩存頁(yè)的數(shù)據(jù)，等到合適的時(shí)間點(diǎn)，再將這個(gè)緩存頁(yè)持久化到磁盤(pán)。而 Buffer Pool 中所有緩存頁(yè)都是處于內(nèi)存當(dāng)中的，當(dāng) MySQL 宕機(jī)或者機(jī)器斷電，內(nèi)存中的數(shù)據(jù)就會(huì)丟失，因此 MySQL 為了防止緩存頁(yè)中的數(shù)據(jù)在更新后出現(xiàn)數(shù)據(jù)丟失的現(xiàn)象，引入了 redo log 機(jī)制。

當(dāng)進(jìn)行增刪改操作時(shí)，MySQL 會(huì)在更新 Buffer Pool 中的緩存頁(yè)數(shù)據(jù)時(shí)，會(huì)記錄一條對(duì)應(yīng)操作的 redo log 日志，這樣如果出現(xiàn) MySQL 宕機(jī)或者斷電時(shí)，如果有緩存頁(yè)的數(shù)據(jù)還沒(méi)來(lái)得及刷入磁盤(pán)，那么當(dāng) MySQL 重新啟動(dòng)時(shí)，可以根據(jù) redo log 日志文件，進(jìn)行數(shù)據(jù)重做，將數(shù)據(jù)恢復(fù)到宕機(jī)或者斷電前的狀態(tài)，保證了更新的數(shù)據(jù)不丟失，因此 redo log 又叫做重做日志。它的本質(zhì)是保證事務(wù)提交后，更新的數(shù)據(jù)不丟失。——用它來(lái)實(shí)現(xiàn)事務(wù)的持久性。

1.1 作用

確保事務(wù)的持久性。防止在發(fā)生故障的時(shí)間點(diǎn)，尚有臟頁(yè)未寫(xiě)入磁盤(pán)，在重啟mysql服務(wù)的時(shí)候，根據(jù)redo log進(jìn)行重做，從而達(dá)到事務(wù)的持久性這一特性。

1.2 內(nèi)容

物理格式的日志，記錄的是物理數(shù)據(jù)頁(yè)面的修改的信息，其redo log是順序?qū)懭雛edo log file的物理文件中去的。

1.3 物理文件

默認(rèn)情況下，對(duì)應(yīng)的物理文件位于數(shù)據(jù)庫(kù)的data目錄下的 ib_logfile1&ib_logfile2

• innodb_log_group_home_dir 指定日志文件組所在的路徑，默認(rèn)./ ，表示在數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄下。
• innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量，默認(rèn)2
• 關(guān)于文件的大小和數(shù)量，由以下兩個(gè)參數(shù)配置
  • innodb_log_file_size 重做日志文件的大小。
  • innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量，默認(rèn)1

1.3 產(chǎn)生時(shí)機(jī)

事務(wù)開(kāi)始之后就產(chǎn)生redo log，redo log的落盤(pán)并不是隨著事務(wù)的提交才寫(xiě)入的，而是在事務(wù)的執(zhí)行過(guò)程中，便開(kāi)始寫(xiě)入redo log文件中。

1.4 釋放時(shí)機(jī)

當(dāng)對(duì)應(yīng)事務(wù)的臟頁(yè)寫(xiě)入到磁盤(pán)之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。

1.6 寫(xiě)盤(pán)時(shí)機(jī)

很重要一點(diǎn)，redo log是什么時(shí)候?qū)懕P(pán)的？

前面說(shuō)了是在事物開(kāi)始之后逐步寫(xiě)盤(pán)的。之所以說(shuō)重做日志是在事務(wù)開(kāi)始之后逐步寫(xiě)入重做日志文件，而不一定是事務(wù)提交才寫(xiě)入重做日志緩存，原因就是，重做日志有一個(gè)緩存區(qū)Innodb_log_buffer，默認(rèn)大小為8M，Innodb存儲(chǔ)引擎先將重做日志寫(xiě)入innodb_log_buffer中。

然后可以通過(guò)以下三種方式將innodb日志緩沖區(qū)的日志刷新到磁盤(pán)

Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件。

每個(gè)事務(wù)提交時(shí)會(huì)將重做日志刷新到重做日志文件。

當(dāng)重做日志緩存可用空間 少于一半時(shí)，重做日志緩存被刷新到重做日志文件

由此可以看出，重做日志通過(guò)不止一種方式寫(xiě)入到磁盤(pán)，尤其是對(duì)于第一種方式，Innodb_log_buffer 到重做日志文件是 Master Thread 線程的定時(shí)任務(wù)。因此重做日志的寫(xiě)盤(pán)，并不一定是隨著事務(wù)的提交才寫(xiě)入重做日志文件的，而是隨著事務(wù)的開(kāi)始，逐步開(kāi)始的。

另外引用《MySQL技術(shù)內(nèi)幕 Innodb 存儲(chǔ)引擎》上的原話：

即使某個(gè)事務(wù)還沒(méi)有提交，Innodb存儲(chǔ)引擎仍然每秒會(huì)將重做日志緩存刷新到重做日志文件。這一點(diǎn)是必須要知道的，因?yàn)檫@可以很好地解釋再大的事務(wù)的提交（commit）的時(shí)間也是很短暫的。

?

2.回滾日志（undo log）

數(shù)據(jù)庫(kù)事務(wù)四大特性中有一個(gè)是原子性，具體來(lái)說(shuō)就是原子性是指對(duì)數(shù)據(jù)庫(kù)的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況。

實(shí)際上，原子性底層就是通過(guò)undo log實(shí)現(xiàn)的。undo log主要記錄了數(shù)據(jù)的邏輯變化，比如一條INSERT語(yǔ)句，對(duì)應(yīng)一條DELETE的undo log，對(duì)于每個(gè)UPDATE語(yǔ)句，對(duì)應(yīng)一條相反的UPDATE的undo log，這樣在發(fā)生錯(cuò)誤時(shí)，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)

2.1 作用

記錄了事務(wù)發(fā)生之前的數(shù)據(jù)狀態(tài)（不包括select） ，如果修改數(shù)據(jù)時(shí)出現(xiàn)異常，可以用undo log來(lái)實(shí)現(xiàn)回滾操作（保持原子性）。同時(shí)可以提供多版本并發(fā)控制下的讀（MVCC），也即非鎖定讀。

2.2 內(nèi)容

邏輯格式的日志，可以簡(jiǎn)單認(rèn)為就是執(zhí)行過(guò)的事務(wù)中的sql語(yǔ)句。但又不完全是sql語(yǔ)句這么簡(jiǎn)單，而是包括了執(zhí)行的sql語(yǔ)句（增刪改）反向的信息，也就意味著

• delete對(duì)應(yīng)著delete本身和其反向的insert
• update對(duì)應(yīng)著update執(zhí)行前后的版本的信息
• insert對(duì)應(yīng)著delete和insert本身的信息

在執(zhí)行undo的時(shí)候，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)，而不是從物理頁(yè)面上操作實(shí)現(xiàn)的，這一點(diǎn)是不同于redo log的。

2.3 物理文件

MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認(rèn)的名稱(chēng)是ibdata，位于數(shù)據(jù)文件目錄中。

MySQL5.6之后，undo表空間可以配置成獨(dú)立的文件，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫(kù)初始化后生效且不可改變undo log文件的個(gè)數(shù)。如果初始化數(shù)據(jù)庫(kù)之前沒(méi)有進(jìn)行相關(guān)配置，那么就無(wú)法配置成獨(dú)立的表空間了。
　　　　
關(guān)于MySQL5.7之后的獨(dú)立undo 表空間配置參數(shù)如下

• innodb_undo_directory = /data/undospace/ --undo獨(dú)立表空間的存放目錄
• innodb_undo_logs = 128 --回滾段為128KB
• innodb_undo_tablespaces = 4 --指定有4個(gè)undo log文件

如果undo使用的共享表空間，這個(gè)共享表空間中又不僅僅是存儲(chǔ)了undo的信息，共享表空間的默認(rèn)為與MySQL的數(shù)據(jù)目錄下面，其屬性由參數(shù) innodb_data_file_path 配置。

默認(rèn)情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當(dāng)數(shù)據(jù)庫(kù)中發(fā)生一些大的事務(wù)性操作的時(shí)候，要生成大量的undo信息，全部保存在共享表空間中的。因此共享表空間可能會(huì)變的很大，默認(rèn)情況下，也就是 undo 日志使用共享表空間的時(shí)候，被“撐大”的共享表空間是不會(huì)也不能自動(dòng)收縮的。

因此，mysql5.7之后的“獨(dú)立undo 表空間”的配置就顯得很有必要了。

2.4 產(chǎn)生時(shí)機(jī)

事務(wù)開(kāi)始之前，將當(dāng)前是的版本生成undo log，undo 也會(huì)產(chǎn)生 redo 來(lái)保證undo log的可靠性

2.5 釋放時(shí)機(jī)

當(dāng)事務(wù)提交之后，undo log并不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務(wù)在使用undo段中表的上一個(gè)事務(wù)之前的版本信息，決定是否可以清理undo log的日志空間。

2.6 undo log 和 redo log

undo是在事務(wù)開(kāi)始之前保存的被修改數(shù)據(jù)的一個(gè)版本，產(chǎn)生undo日志的時(shí)候，同樣會(huì)伴隨類(lèi)似于保護(hù)事務(wù)持久化機(jī)制的redo log的產(chǎn)生。

• Redo 記錄某?數(shù)據(jù)塊?被修改?后?的值，可以用來(lái)恢復(fù)未寫(xiě)入 data file 的已成功事務(wù)更新的數(shù)據(jù)。-- 保證事務(wù)持久性
• Undo 記錄某?數(shù)據(jù)?被修改?前?的值，可以用來(lái)在事務(wù)失敗時(shí)進(jìn)行 rollback；-- 保證事務(wù)原子性

比如某一時(shí)刻數(shù)據(jù)庫(kù) DOWN 機(jī)了，有兩個(gè)事務(wù)，一個(gè)事務(wù)已經(jīng)提交，另一個(gè)事務(wù)正在處理。數(shù)據(jù)庫(kù)重啟的時(shí)候就要根據(jù)日志進(jìn)行前滾及回滾，把已提交事務(wù)的更改寫(xiě)到數(shù)據(jù)文件，未提交事務(wù)的更改恢復(fù)到事務(wù)開(kāi)始前的狀態(tài)。

• 當(dāng)數(shù)據(jù) crash-recovery 時(shí)，通過(guò) redo log 將所有已經(jīng)在存儲(chǔ)引擎內(nèi)部提交的事務(wù)應(yīng)用 redo log 恢復(fù)
• 所有已經(jīng) prepared 但是沒(méi)有 commit 的 transactions 將會(huì)應(yīng)用 undo log 做 roll back

問(wèn)題一：可不可以只用 undo 或只用 redo？

假設(shè)只有 undo-log：那么就必須保證提交前刷臟完成，否則宕機(jī)時(shí)有些修改就在內(nèi)存中丟失了，破壞了持久性。（這樣帶來(lái)了一個(gè)問(wèn)題，那就是前面提到的性能差）

假設(shè)只有 redo-log：那么就不能隨心所欲地在事務(wù)提交前刷臟，即無(wú)法支持大事務(wù)。（假如、某張表有 100 億的 8 字節(jié)整數(shù)數(shù)據(jù)，就算不考慮其他東西帶來(lái)的損耗，光 update 整張表至少要消耗 80G 的內(nèi)存。如前所述，有了 undo-log，就可以隨便刷臟）

問(wèn)題二：說(shuō)了這么多，undo+redo 有什么示例嗎？

示例一：假設(shè)有A、B兩個(gè)數(shù)據(jù)，值分別為1,2。現(xiàn)在要將A修改成3，B修改成4。

A.事務(wù)開(kāi)始. 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寫(xiě)入磁盤(pán)。 I.事務(wù)提交

示例二：update過(guò)程分析。一個(gè)更新操作的流程，這是一個(gè)簡(jiǎn)化的過(guò)程（name原值是zhangsan）。

update user set name='penyuyan' where id=1; 1. 事務(wù)開(kāi)始，從內(nèi)存或磁盤(pán)取到這條數(shù)據(jù)，返回給Server 的執(zhí)行器； 2. 執(zhí)行器修改這一行數(shù)據(jù)的值為penyuyan； 3. 記錄 name=zhangsan 到 undo log； 4. 記錄 name=penyuyan 到 redo log； 5. 調(diào)用存儲(chǔ)引擎接口，在內(nèi)存（Buffer Pool）中修改 name=zhangsan； 6. 事務(wù)提交

3.二進(jìn)制日志（binlog）

3.1 作用

用于復(fù)制，在主從復(fù)制中，從庫(kù)利用主庫(kù)上的binlog進(jìn)行重播，實(shí)現(xiàn)主從同步。

用于數(shù)據(jù)庫(kù)的基于時(shí)間點(diǎn)的還原。

3.2 內(nèi)容

bin log有三種格式,分別為STATMENT、ROW、和MIXED。

• STATMENT：基于SQL語(yǔ)句的復(fù)制(statement-based-replication,SBR),所有涉及到數(shù)據(jù)修改的sql語(yǔ)句都會(huì)記錄到bin log中
  • 優(yōu)點(diǎn) ：不需要記錄每一行的變化，減少bin log日質(zhì)量，節(jié)約IO，所以性能最好.
  • 缺點(diǎn):可能會(huì)在某些情況下導(dǎo)致主從數(shù)據(jù)不一致，例如執(zhí)行sysdate()、sleep;
• ROW：基于行變化的復(fù)制(row-based replication,RBR),不需要記錄每一條sql語(yǔ)句信息,僅需要記錄哪一條數(shù)據(jù)被修改了.
  • 優(yōu)點(diǎn)：不會(huì)出現(xiàn)某些情況下的存儲(chǔ)過(guò)程、函數(shù)、觸發(fā)器調(diào)用無(wú)法被正確復(fù)制和回復(fù)的情況.
  • 缺點(diǎn)：日志數(shù)量會(huì)增多,尤其是是在執(zhí)行alter table的時(shí)候日志會(huì)暴漲
• MIXED：顧名思義就是以上兩種的混合使用模式(mixed-based replication,MBR),一般的復(fù)制使用STATEMENT，而對(duì)于STATEMENT無(wú)法復(fù)制的則使用ROW模式。

因此可以基于binlog做到類(lèi)似于oracle的閃回功能，其實(shí)都是依賴(lài)于binlog中的日志記錄。

3.3 物理文件

配置文件的路徑為log_bin_basename，binlog日志文件按照指定大小，當(dāng)日志文件達(dá)到指定的最大的大小之后，進(jìn)行滾動(dòng)更新，生成新的日志文件。

對(duì)于每個(gè)binlog日志文件，通過(guò)一個(gè)統(tǒng)一的index文件來(lái)組織。

3.4 產(chǎn)生時(shí)機(jī)

事務(wù)提交的時(shí)候，一次性將事務(wù)中的sql語(yǔ)句（一個(gè)事物可能對(duì)應(yīng)多個(gè)sql語(yǔ)句）按照一定的格式記錄到binlog中。

這里與redo log很明顯的差異就是redo log并不一定是在事務(wù)提交的時(shí)候刷新到磁盤(pán)，redo log是在事務(wù)開(kāi)始之后就開(kāi)始逐步寫(xiě)入磁盤(pán)。

因此對(duì)于事務(wù)的提交，即便是較大的事務(wù)，提交（commit）都是很快的，但是在開(kāi)啟了bin_log的情況下，對(duì)于較大事務(wù)的提交，可能會(huì)變得比較慢一些。這是因?yàn)閎inlog是在事務(wù)提交的時(shí)候一次性寫(xiě)入的造成的，這些可以通過(guò)測(cè)試驗(yàn)證。

3.5 釋放時(shí)機(jī)

binlog的默認(rèn)是保持時(shí)間由參數(shù)expire_logs_days配置，也就是說(shuō)對(duì)于非活動(dòng)的日志文件，在生成時(shí)間超過(guò)expire_logs_days配置的天數(shù)之后，會(huì)被自動(dòng)刪除。

3.6 redo/undo log 和 binlog

二進(jìn)制日志的作用之一是還原數(shù)據(jù)庫(kù)的，這與redo/undo log很類(lèi)似，但兩者區(qū)別還是挺多的，大致如下：

• 層次不同
  • redo/undo 是 innodb 引擎層維護(hù)的，是保證事務(wù)的持久性的，是事務(wù)層面的。
  • binlog 是 mysql server 層維護(hù)的，跟采用何種引擎沒(méi)有關(guān)系，記錄的是所有引擎的更新操作的日志記錄。雖然都有還原的意思，但是其保護(hù)數(shù)據(jù)的層次是不一樣的。
• 記錄內(nèi)容不同
  • redo/undo 記錄的是 每個(gè)頁(yè)/每個(gè)數(shù)據(jù) 的修改情況，屬于物理日志+邏輯日志結(jié)合的方式（redo log 是物理日志，undo log 是邏輯日志）。
  • binlog 記錄的都是事務(wù)操作內(nèi)容，binlog 有三種模式：Statement（基于 SQL 語(yǔ)句的復(fù)制）、Row（基于行的復(fù)制） 以及 Mixed（混合模式）。不管采用的是什么模式，當(dāng)然格式是二進(jìn)制的。
• 記錄時(shí)機(jī)不同
  • redo/undo 在 事務(wù)執(zhí)行過(guò)程中會(huì)不斷的寫(xiě)入。
  • binlog 是在事務(wù)最終提交前寫(xiě)入的。binlog 什么時(shí)候刷新到磁盤(pán)跟參數(shù) sync_binlog 相關(guān)。

關(guān)于事務(wù)提交時(shí)，redo log 和 binlog的寫(xiě)入順序，為了保證主從復(fù)制時(shí)候的主從一致（當(dāng)然也包括使用binlog進(jìn)行基于時(shí)間點(diǎn)還原的情況），是要嚴(yán)格一致的，

MySQL通過(guò)兩階段提交過(guò)程來(lái)完成事務(wù)的一致性的，也即redo log和binlog的一致性的，理論上是先寫(xiě)redo log，再寫(xiě)binlog，兩個(gè)日志都提交成功（刷入磁盤(pán)），事務(wù)才算真正的完成。參考鏈接…

總結(jié)

以上是生活随笔為你收集整理的【转】【MySQL】运行原理（四）：重做日志（redo log），回滚日志（undo log），二进制日志（binlog）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。