必須了解的mysql三大日志-binlog、redo log和undo log

往期熱門文章：

1、推薦 15 款常用開發(fā)工具
2、一次 QPS 翻倍的 Java 服務(wù)性能優(yōu)化
3、Maven 劃分模塊最佳實(shí)踐
4、面試官問：select......for update會(huì)鎖表還是鎖行？
5、Spring Boot + GraphQL 才是 API 的未來！

來源：https://juejin.cn/post/6860252224930070536

| 背景

日志是 mysql 數(shù)據(jù)庫的重要組成部分，記錄著數(shù)據(jù)庫運(yùn)行期間各種狀態(tài)信息。mysql日志主要包括錯(cuò)誤日志、查詢?nèi)罩尽⒙樵內(nèi)罩尽⑹聞?wù)日志、二進(jìn)制日志幾大類。

作為開發(fā)，我們重點(diǎn)需要關(guān)注的是二進(jìn)制日志( binlog )和事務(wù)日志(包括redo log 和 undo log )，本文接下來會(huì)詳細(xì)介紹這三種日志。

| binlog

binlog 用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進(jìn)制的形式保存在磁盤中。binlog 是 mysql的邏輯日志，并且由 Server 層進(jìn)行記錄，使用任何存儲(chǔ)引擎的 mysql 數(shù)據(jù)庫都會(huì)記錄 binlog 日志。

• 邏輯日志：可以簡單理解為記錄的就是sql語句 。
• 物理日志：mysql 數(shù)據(jù)最終是保存在數(shù)據(jù)頁中的，物理日志記錄的就是數(shù)據(jù)頁變更 。

binlog 是通過追加的方式進(jìn)行寫入的，可以通過max_binlog_size 參數(shù)設(shè)置每個(gè) binlog文件的大小，當(dāng)文件大小達(dá)到給定值之后，會(huì)生成新的文件來保存日志。

binlog使用場(chǎng)景

在實(shí)際應(yīng)用中， binlog 的主要使用場(chǎng)景有兩個(gè)，分別是 主從復(fù)制 和 數(shù)據(jù)恢復(fù) 。

1. 主從復(fù)制 ：在 Master 端開啟 binlog ，然后將 binlog發(fā)送到各個(gè) Slave 端， Slave 端重放 binlog 從而達(dá)到主從數(shù)據(jù)一致。
2. 數(shù)據(jù)恢復(fù) ：通過使用 mysqlbinlog 工具來恢復(fù)數(shù)據(jù)。

binlog刷盤時(shí)機(jī)

對(duì)于 InnoDB 存儲(chǔ)引擎而言，只有在事務(wù)提交時(shí)才會(huì)記錄biglog ，此時(shí)記錄還在內(nèi)存中，那么 biglog是什么時(shí)候刷到磁盤中的呢？

mysql 通過 sync_binlog 參數(shù)控制 biglog 的刷盤時(shí)機(jī)，取值范圍是 0-N：

• 0：不去強(qiáng)制要求，由系統(tǒng)自行判斷何時(shí)寫入磁盤；
• 1：每次 commit 的時(shí)候都要將 binlog 寫入磁盤；
• N：每N個(gè)事務(wù)，才會(huì)將 binlog 寫入磁盤。

從上面可以看出， sync_binlog 最安全的是設(shè)置是 1 ，這也是MySQL 5.7.7之后版本的默認(rèn)值。但是設(shè)置一個(gè)大一些的值可以提升數(shù)據(jù)庫性能，因此實(shí)際情況下也可以將值適當(dāng)調(diào)大，犧牲一定的一致性來獲取更好的性能。

binlog日志格式

binlog 日志有三種格式，分別為 STATMENT 、 ROW 和 MIXED。

在 MySQL 5.7.7 之前，默認(rèn)的格式是 STATEMENT ， MySQL 5.7.7 之后，默認(rèn)值是 ROW。日志格式通過 binlog-format 指定。

• STATMENT：基于SQL 語句的復(fù)制( statement-based replication, SBR )，每一條會(huì)修改數(shù)據(jù)的sql語句會(huì)記錄到binlog 中  。
• 
  
• 優(yōu)點(diǎn)：不需要記錄每一行的變化，減少了 binlog 日志量，節(jié)約了 IO  , 從而提高了性能；
• 缺點(diǎn)：在某些情況下會(huì)導(dǎo)致主從數(shù)據(jù)不一致，比如執(zhí)行sysdate() 、  slepp()  等 。
• ROW：基于行的復(fù)制(row-based replication, RBR )，不記錄每條sql語句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了 。
• 
  
• 優(yōu)點(diǎn)：不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過程、或function、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題 ；
• 缺點(diǎn)：會(huì)產(chǎn)生大量的日志，尤其是alter table 的時(shí)候會(huì)讓日志暴漲
• MIXED：基于STATMENT 和 ROW 兩種模式的混合復(fù)制(mixed-based replication, MBR )，一般的復(fù)制使用STATEMENT 模式保存 binlog ，對(duì)于 STATEMENT 模式無法復(fù)制的操作使用 ROW 模式保存 binlog

| redo log

為什么需要redo log

我們都知道，事務(wù)的四大特性里面有一個(gè)是 持久性 ，具體來說就是只要事務(wù)提交成功，那么對(duì)數(shù)據(jù)庫做的修改就被永久保存下來了，不可能因?yàn)槿魏卧蛟倩氐皆瓉淼臓顟B(tài) 。

那么 mysql是如何保證一致性的呢？

最簡單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。但是這么做會(huì)有嚴(yán)重的性能問題，主要體現(xiàn)在兩個(gè)方面：

1. 因?yàn)?nbsp;Innodb 是以 頁 為單位進(jìn)行磁盤交互的，而一個(gè)事務(wù)很可能只修改一個(gè)數(shù)據(jù)頁里面的幾個(gè)字節(jié)，這個(gè)時(shí)候?qū)⑼暾臄?shù)據(jù)頁刷到磁盤的話，太浪費(fèi)資源了！
2. 一個(gè)事務(wù)可能涉及修改多個(gè)數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機(jī)IO寫入性能太差！

因此 mysql 設(shè)計(jì)了 redo log ， 具體來說就是只記錄事務(wù)對(duì)數(shù)據(jù)頁做了哪些修改，這樣就能完美地解決性能問題了(相對(duì)而言文件更小并且是順序IO)。

redo log基本概念

redo log 包括兩部分：一個(gè)是內(nèi)存中的日志緩沖( redo log buffer )，另一個(gè)是磁盤上的日志文件( redo logfile)。

mysql 每執(zhí)行一條 DML 語句，先將記錄寫入 redo log buffer，后續(xù)某個(gè)時(shí)間點(diǎn)再一次性將多個(gè)操作記錄寫到 redo log file。這種 先寫日志，再寫磁盤 的技術(shù)就是 MySQL里經(jīng)常說到的 WAL(Write-Ahead Logging) 技術(shù)。

在計(jì)算機(jī)操作系統(tǒng)中，用戶空間( user space )下的緩沖區(qū)數(shù)據(jù)一般情況下是無法直接寫入磁盤的，中間必須經(jīng)過操作系統(tǒng)內(nèi)核空間( kernel space )緩沖區(qū)( OS Buffer )。

因此， redo log buffer 寫入 redo logfile 實(shí)際上是先寫入 OS Buffer ，然后再通過系統(tǒng)調(diào)用 fsync() 將其刷到 redo log file中，過程如下：

mysql 支持三種將 redo log buffer 寫入 redo log file 的時(shí)機(jī)，可以通過 innodb_flush_log_at_trx_commit 參數(shù)配置，各參數(shù)值含義如下：

redo log記錄形式

前面說過， redo log 實(shí)際上記錄數(shù)據(jù)頁的變更，而這種變更記錄是沒必要全部保存，因此 redo log實(shí)現(xiàn)上采用了大小固定，循環(huán)寫入的方式，當(dāng)寫到結(jié)尾時(shí)，會(huì)回到開頭循環(huán)寫日志。

如下圖：

同時(shí)我們很容易得知， 在innodb中，既有redo log 需要刷盤，還有 數(shù)據(jù)頁 也需要刷盤， redo log存在的意義主要就是降低對(duì) 數(shù)據(jù)頁 刷盤的要求。

在上圖中， write pos 表示 redo log 當(dāng)前記錄的 LSN (邏輯序列號(hào))位置， check point 表示 數(shù)據(jù)頁更改記錄 刷盤后對(duì)應(yīng) redo log 所處的 LSN(邏輯序列號(hào))位置。

write pos 到 check point 之間的部分是 redo log 空著的部分，用于記錄新的記錄；check point 到 write pos 之間是 redo log 待落盤的數(shù)據(jù)頁更改記錄。當(dāng) write pos追上check point 時(shí)，會(huì)先推動(dòng) check point 向前移動(dòng)，空出位置再記錄新的日志。

啟動(dòng) innodb 的時(shí)候，不管上次是正常關(guān)閉還是異常關(guān)閉，總是會(huì)進(jìn)行恢復(fù)操作。因?yàn)?nbsp;redo log記錄的是數(shù)據(jù)頁的物理變化，因此恢復(fù)的時(shí)候速度比邏輯日志(如 binlog )要快很多。

重啟innodb 時(shí)，首先會(huì)檢查磁盤中數(shù)據(jù)頁的 LSN ，如果數(shù)據(jù)頁的LSN 小于日志中的 LSN ，則會(huì)從 checkpoint 開始恢復(fù)。

還有一種情況，在宕機(jī)前正處于checkpoint 的刷盤過程，且數(shù)據(jù)頁的刷盤進(jìn)度超過了日志頁的刷盤進(jìn)度，此時(shí)會(huì)出現(xiàn)數(shù)據(jù)頁中記錄的 LSN 大于日志中的 LSN，這時(shí)超出日志進(jìn)度的部分將不會(huì)重做，因?yàn)檫@本身就表示已經(jīng)做過的事情，無需再重做。

redo log與binlog區(qū)別

由 binlog 和 redo log 的區(qū)別可知：binlog 日志只用于歸檔，只依靠 binlog 是沒有 crash-safe 能力的。

但只有 redo log 也不行，因?yàn)?nbsp;redo log 是 InnoDB特有的，且日志上的記錄落盤后會(huì)被覆蓋掉。因此需要 binlog和 redo log二者同時(shí)記錄，才能保證當(dāng)數(shù)據(jù)庫發(fā)生宕機(jī)重啟時(shí)，數(shù)據(jù)不會(huì)丟失。

| undo log

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

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

同時(shí)， undo log 也是 MVCC(多版本并發(fā)控制)實(shí)現(xiàn)的關(guān)鍵。

最近熱文閱讀：
1、推薦 15 款常用開發(fā)工具
2、一次 QPS 翻倍的 Java 服務(wù)性能優(yōu)化
3、Maven 劃分模塊最佳實(shí)踐
4、面試官問：select......for update會(huì)鎖表還是鎖行？
5、Spring Boot + GraphQL 才是 API 的未來！
6、一個(gè)基于 SpringBoot2+redis+Vue 的商城管理系統(tǒng)，拼團(tuán)、砍價(jià)、秒殺等都有，可二次開發(fā)接私活！
7、用 MySQL 實(shí)現(xiàn)分布式鎖，你聽過嗎？
8、全員遠(yuǎn)程辦公，半年入 1 億美元：GitHub 的最大競(jìng)爭對(duì)手上市了！
9、面試官：Spring AOP、AspectJ、CGLIB 都是什么鬼？它們有什么關(guān)系？
10、10 個(gè) VSCode 超級(jí)摸魚神器，確定不試一下？
關(guān)注公眾號(hào)，你想要的Java都在這里