免費(fèi)學(xué)習(xí)推薦：mysql視頻教程

目錄

一、簡介

二、redo log

三. binlog

四. 內(nèi)部工作流程

MySql學(xué)習(xí)專欄

1. MySQL基礎(chǔ)架構(gòu)詳解

2. MySQL索引底層數(shù)據(jù)結(jié)構(gòu)與算法

3. MySQL5.7開啟binlog日志，及數(shù)據(jù)恢復(fù)簡單示例

4. MySQL日志模塊

一、簡介

MySQL 有兩大重要的日志模塊：redo log（重做日志）和 binlog（歸檔日志）。

redo log是InnoDB存儲引擎層的日志，binlog是MySQL Server層記錄的日志， 兩者都是記錄了某些操作的日志，但兩者記錄的格式不同。

二、redo log

redo log: 又稱（重做日志）文件，用于記錄事務(wù)操作的變化，記錄的是數(shù)據(jù)修改之后的值，不管事務(wù)是否提交都會記錄下來。

在media failure時(shí)，redo log文件就能派上用場，如數(shù)據(jù)庫掉電，InnoDB存儲引擎會使用redo log恢復(fù)到掉電前的時(shí)刻，以此來保證數(shù)據(jù)的完整性。

當(dāng)有一條記錄需要更新的時(shí)候，InnoDB 引擎就會先把記錄寫到 redo log 里面，并更新內(nèi)存，這個(gè)時(shí)候更新就算完成了。

InnoDB 引擎會在適當(dāng)?shù)臅r(shí)候，將這個(gè)操作記錄更新到磁盤里面，而這個(gè)更新一般是在系統(tǒng)比較空閑的時(shí)候完成的，以此來提升更新效率。

這里涉及到 WAL 即 Write-Ahead Logging 技術(shù)，他的關(guān)鍵點(diǎn)就是 先寫日志，再寫磁盤。

InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個(gè)文件，每個(gè)文件的大小是 1GB，那么總共就可以記錄 4GB 的操作。

redo log會從頭開始寫，寫到末尾就又回到開頭循環(huán)寫，如下圖所示。

write pos 是當(dāng)前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到 0 號文件開頭。

check point 是當(dāng)前要擦除的位置，也是往后推移并且循環(huán)的，擦除記錄前要把記錄更新到數(shù)據(jù)文件。

write pos 和 check point 之間的是未使用的部分，可以用來記錄新的操作。

如果 write pos 追上 check point，表示redo log記錄滿了，這時(shí)候不能再執(zhí)行新的更新，得停下來先擦掉一些記錄，把 check point 推進(jìn)一下。

有了 redo log，InnoDB 就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失，這個(gè)能力稱為 crash-safe。

為什么要使用redo log日志？

假如我們對數(shù)據(jù)庫進(jìn)行DML操作，直接把執(zhí)行SQL寫入磁盤，當(dāng)寫入并發(fā)較大時(shí)，對數(shù)據(jù)寫入磁盤的壓力會造成一定影響，

當(dāng)我們插入操作是，發(fā)現(xiàn)當(dāng)前非葉子節(jié)點(diǎn)一頁數(shù)據(jù)量不夠時(shí)，要進(jìn)行分頁算法，效率會比較低；

當(dāng)我使用redo log日志，先把我們DML操作寫入日志，通過一個(gè)"中轉(zhuǎn)站",空閑時(shí)候再通過check point 寫入磁盤，效率會高很多；

MySQL設(shè)置Redo Log

• 寫入日innodb_log_buffer_size的大?。海J(rèn)8M）
• innodb_log_file_size 重做日志文件的大小。
• innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量，默認(rèn)2
• innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量，默認(rèn)1
• innodb_log_group_home_dir 指定日志文件組所在的路徑，默認(rèn)./,表示在數(shù)據(jù)庫的數(shù)據(jù)目錄下
• innodb_flush_log_at_trx_commit 設(shè)置commit時(shí)如何將log buffer中日志刷log file中 （值0、1、2）默認(rèn)1

三. binlog

redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，稱為 binlog（歸檔日志）。

為什么會有兩份日志呢？

因?yàn)樽铋_始 MySQL 里并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM，但是 MyISAM 沒有 crash-safe 的能力，binlog 日志只能用于歸檔。

而 InnoDB 是另一個(gè)公司以插件形式引入 MySQL 的，既然只依靠 binlog 是沒有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系統(tǒng)——也就是 redo log 來實(shí)現(xiàn) crash-safe 能力。

這兩種日志有以下三點(diǎn)不同。

• redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實(shí)現(xiàn)的，所有引擎都可以使用。
• redo log 是物理日志，記錄的是 "在某個(gè)數(shù)據(jù)頁上做了什么修改" ；binlog 是邏輯日志，記錄的是這個(gè)語句的原始邏輯，比如 "給 ID=2 這一行的 c 字段加 1" 。
• redo log 是循環(huán)寫的，空間固定會用完；binlog 是可以追加寫入的。 "追加寫" 是指 binlog 文件寫到一定大小后會切換到下一個(gè)，并不會覆蓋以前的日志。

四. 內(nèi)部工作流程

以一個(gè)表的更新語句為例，來看一下執(zhí)行器和 InnoDB 引擎的內(nèi)部工作流程：

mysql> update T set c=c+1 where ID=2;

如下圖所示，淺色框表示是在 InnoDB 內(nèi)部執(zhí)行的，深色框表示是在執(zhí)行器中執(zhí)行的：

• 執(zhí)行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果 ID=2 這一行所在的數(shù)據(jù)頁本來就在內(nèi)存中，就直接返回給執(zhí)行器；否則，需要先從磁盤讀入內(nèi)存，然后再返回。
• 執(zhí)行器拿到引擎給的行數(shù)據(jù)，把這個(gè)值加上 1，比如原來是 N，現(xiàn)在就是 N+1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫入這行新數(shù)據(jù)。
• 引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個(gè)更新操作記錄到 redo log 里面，此時(shí) redo log 處于 prepare 狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時(shí)可以提交事務(wù)。
• 執(zhí)行器生成這個(gè)操作的 binlog，并把 binlog 寫入磁盤。
• 執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態(tài)，更新完成。

最后三步看上去有點(diǎn)“繞”，將 redo log 的寫入拆成了兩個(gè)步驟：prepare 和 commit，其實(shí)這就是 "兩階段提交"。

為什么日志需要 "兩階段提交"？這里可以用反證法來進(jìn)行解釋。

由于 redo log 和 binlog 是兩個(gè)獨(dú)立的邏輯，如果不用兩階段提交，要么就是先寫完 redo log 再寫 binlog，或者采用反過來的順序。用前面的 update 語句來做例子，我們看看這兩種方式會有什么問題。

假設(shè)當(dāng)前 ID=2 的行，字段 c 的值是 0，再假設(shè)執(zhí)行 update 語句過程中在寫完第一個(gè)日志后，第二個(gè)日志還沒有寫完期間發(fā)生了 crash，會出現(xiàn)什么情況呢？

1. 先寫 redo log 后寫 binlog。假設(shè)在 redo log 寫完，binlog 還沒有寫完的時(shí)候，MySQL 進(jìn)程異常重啟。redo log 寫完之后，系統(tǒng)即使崩潰，仍然能夠把數(shù)據(jù)恢復(fù)回來，所以恢復(fù)后這一行 c 的值是 1。

但是由于 binlog 沒寫完就 crash 了，這時(shí)候 binlog 里面就沒有記錄這個(gè)語句。因此，之后備份日志的時(shí)候，存起來的 binlog 里面就沒有這條語句。

然后你會發(fā)現(xiàn)，如果需要用這個(gè) binlog 來恢復(fù)臨時(shí)庫的話，由于這個(gè)語句的 binlog 丟失，這個(gè)臨時(shí)庫就會少了這一次更新，恢復(fù)出來的這一行 c 的值就是 0，與原庫的值不同。

2. 先寫 binlog 后寫 redo log。如果在 binlog 寫完之后 crash，由于 redo log 還沒寫，崩潰恢復(fù)以后這個(gè)事務(wù)無效，所以這一行 c 的值是 0。

但是 binlog 里面已經(jīng)記錄了“把 c 從 0 改成 1”這個(gè)日志。所以，在之后用 binlog 來恢復(fù)的時(shí)候就多了一個(gè)事務(wù)出來，恢復(fù)出來的這一行 c 的值就是 1，與原庫的值不同。

可以看到，如果不使用“兩階段提交”，那么數(shù)據(jù)庫的狀態(tài)就有可能和用它的日志恢復(fù)出來的庫的狀態(tài)不一致。

相關(guān)免費(fèi)學(xué)習(xí)推薦：mysql數(shù)據(jù)庫(視頻)