binlog/redo log/undo log？再也不會(huì)傻傻分不清楚了
來(lái)源：juejin.cn/post/6860252224930070536
日志是 mysql 數(shù)據(jù)庫(kù)的重要組成部分，記錄著數(shù)據(jù)庫(kù)運(yùn)行期間各種狀態(tài)信息。mysql日志主要包括錯(cuò)誤日志、查詢?nèi)罩?、慢查詢?nèi)罩尽⑹聞?wù)日志、二進(jìn)制日志幾大類。
作為開(kāi)發(fā)，我們重點(diǎn)需要關(guān)注的是二進(jìn)制日志( binlog )和事務(wù)日志(包括redo log 和 undo log )，本文接下來(lái)會(huì)詳細(xì)介紹這三種日志。
binlog
binlog 用于記錄數(shù)據(jù)庫(kù)執(zhí)行的寫(xiě)入性操作(不包括查詢)信息，以二進(jìn)制的形式保存在磁盤(pán)中。binlog 是 mysql的邏輯日志，并且由 Server 層進(jìn)行記錄，使用任何存儲(chǔ)引擎的 mysql 數(shù)據(jù)庫(kù)都會(huì)記錄 binlog 日志。
邏輯日志 ：可以簡(jiǎn)單理解為記錄的就是sql語(yǔ)句 。 物理日志 ： mysql數(shù)據(jù)最終是保存在數(shù)據(jù)頁(yè)中的，物理日志記錄的就是數(shù)據(jù)頁(yè)變更 。
binlog 是通過(guò)追加的方式進(jìn)行寫(xiě)入的，可以通過(guò)max_binlog_size 參數(shù)設(shè)置每個(gè) binlog文件的大小，當(dāng)文件大小達(dá)到給定值之后，會(huì)生成新的文件來(lái)保存日志。
binlog使用場(chǎng)景
在實(shí)際應(yīng)用中， binlog 的主要使用場(chǎng)景有兩個(gè)，分別是 主從復(fù)制 和 數(shù)據(jù)恢復(fù) 。
主從復(fù)制 ：在 Master端開(kāi)啟binlog，然后將binlog發(fā)送到各個(gè)Slave端，Slave端重放binlog從而達(dá)到主從數(shù)據(jù)一致。數(shù)據(jù)恢復(fù) ：通過(guò)使用 mysqlbinlog工具來(lái)恢復(fù)數(shù)據(jù)。
binlog刷盤(pán)時(shí)機(jī)
對(duì)于 InnoDB 存儲(chǔ)引擎而言，只有在事務(wù)提交時(shí)才會(huì)記錄biglog ，此時(shí)記錄還在內(nèi)存中，那么 biglog是什么時(shí)候刷到磁盤(pán)中的呢？
mysql 通過(guò) sync_binlog 參數(shù)控制 biglog 的刷盤(pán)時(shí)機(jī)，取值范圍是 0-N：
0：不去強(qiáng)制要求，由系統(tǒng)自行判斷何時(shí)寫(xiě)入磁盤(pán)； 1：每次 commit的時(shí)候都要將binlog寫(xiě)入磁盤(pán)；N：每N個(gè)事務(wù)，才會(huì)將 binlog寫(xiě)入磁盤(pán)。
從上面可以看出， sync_binlog 最安全的是設(shè)置是 1 ，這也是MySQL 5.7.7之后版本的默認(rèn)值。但是設(shè)置一個(gè)大一些的值可以提升數(shù)據(jù)庫(kù)性能，因此實(shí)際情況下也可以將值適當(dāng)調(diào)大，犧牲一定的一致性來(lái)獲取更好的性能。
binlog日志格式
binlog 日志有三種格式，分別為 STATMENT 、 ROW 和 MIXED。
在
MySQL 5.7.7之前，默認(rèn)的格式是STATEMENT，MySQL 5.7.7之后，默認(rèn)值是ROW。日志格式通過(guò)binlog-format指定。
STATMENT：基于SQL語(yǔ)句的復(fù)制(statement-based replication, SBR)，每一條會(huì)修改數(shù)據(jù)的sql語(yǔ)句會(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語(yǔ)句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了 。優(yōu)點(diǎn)：不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過(guò)程、或function、或trigger的調(diào)用和觸發(fā)無(wú)法被正確復(fù)制的問(wèn)題 ； 缺點(diǎn)：會(huì)產(chǎn)生大量的日志，尤其是
alter table的時(shí)候會(huì)讓日志暴漲MIXED：基于STATMENT和ROW兩種模式的混合復(fù)制(mixed-based replication, MBR)，一般的復(fù)制使用STATEMENT模式保存binlog，對(duì)于STATEMENT模式無(wú)法復(fù)制的操作使用ROW模式保存binlog
推薦下自己做的 Spring Boot 的實(shí)戰(zhàn)項(xiàng)目：
https://github.com/YunaiV/ruoyi-vue-pro
redo log
為什么需要redo log
我們都知道，事務(wù)的四大特性里面有一個(gè)是 持久性 ，具體來(lái)說(shuō)就是只要事務(wù)提交成功，那么對(duì)數(shù)據(jù)庫(kù)做的修改就被永久保存下來(lái)了，不可能因?yàn)槿魏卧蛟倩氐皆瓉?lái)的狀態(tài) 。
那么 mysql是如何保證一致性的呢？
最簡(jiǎn)單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁(yè)全部刷新到磁盤(pán)中。但是這么做會(huì)有嚴(yán)重的性能問(wèn)題，主要體現(xiàn)在兩個(gè)方面：
因?yàn)? Innodb是以頁(yè)為單位進(jìn)行磁盤(pán)交互的，而一個(gè)事務(wù)很可能只修改一個(gè)數(shù)據(jù)頁(yè)里面的幾個(gè)字節(jié)，這個(gè)時(shí)候?qū)⑼暾臄?shù)據(jù)頁(yè)刷到磁盤(pán)的話，太浪費(fèi)資源了！一個(gè)事務(wù)可能涉及修改多個(gè)數(shù)據(jù)頁(yè)，并且這些數(shù)據(jù)頁(yè)在物理上并不連續(xù)，使用隨機(jī)IO寫(xiě)入性能太差！
因此 mysql 設(shè)計(jì)了 redo log ， 具體來(lái)說(shuō)就是只記錄事務(wù)對(duì)數(shù)據(jù)頁(yè)做了哪些修改 ，這樣就能完美地解決性能問(wèn)題了(相對(duì)而言文件更小并且是順序IO)。
redo log基本概念
redo log 包括兩部分：一個(gè)是內(nèi)存中的日志緩沖( redo log buffer )，另一個(gè)是磁盤(pán)上的日志文件( redo logfile)。
mysql 每執(zhí)行一條 DML 語(yǔ)句，先將記錄寫(xiě)入 redo log buffer，后續(xù)某個(gè)時(shí)間點(diǎn)再一次性將多個(gè)操作記錄寫(xiě)到 redo log file。這種 先寫(xiě)日志，再寫(xiě)磁盤(pán) 的技術(shù)就是 MySQL里經(jīng)常說(shuō)到的 WAL(Write-Ahead Logging) 技術(shù)。
在計(jì)算機(jī)操作系統(tǒng)中，用戶空間( user space )下的緩沖區(qū)數(shù)據(jù)一般情況下是無(wú)法直接寫(xiě)入磁盤(pán)的，中間必須經(jīng)過(guò)操作系統(tǒng)內(nèi)核空間( kernel space )緩沖區(qū)( OS Buffer )。
因此， redo log buffer 寫(xiě)入 redo logfile 實(shí)際上是先寫(xiě)入 OS Buffer ，然后再通過(guò)系統(tǒng)調(diào)用 fsync() 將其刷到 redo log file中，過(guò)程如下：
mysql 支持三種將 redo log buffer 寫(xiě)入 redo log file 的時(shí)機(jī)，可以通過(guò) innodb_flush_log_at_trx_commit 參數(shù)配置，各參數(shù)值含義如下：
redo log記錄形式
前面說(shuō)過(guò)， redo log 實(shí)際上記錄數(shù)據(jù)頁(yè)的變更，而這種變更記錄是沒(méi)必要全部保存，因此 redo log實(shí)現(xiàn)上采用了大小固定，循環(huán)寫(xiě)入的方式，當(dāng)寫(xiě)到結(jié)尾時(shí)，會(huì)回到開(kāi)頭循環(huán)寫(xiě)日志。如下圖：
同時(shí)我們很容易得知， 在innodb中，既有redo log 需要刷盤(pán)，還有 數(shù)據(jù)頁(yè) 也需要刷盤(pán)， redo log存在的意義主要就是降低對(duì) 數(shù)據(jù)頁(yè) 刷盤(pán)的要求 ** 。
在上圖中， write pos 表示 redo log 當(dāng)前記錄的 LSN (邏輯序列號(hào))位置， check point 表示 數(shù)據(jù)頁(yè)更改記錄 刷盤(pán)后對(duì)應(yīng) redo log 所處的 LSN(邏輯序列號(hào))位置。
write pos 到 check point 之間的部分是 redo log 空著的部分，用于記錄新的記錄；check point 到 write pos 之間是 redo log 待落盤(pán)的數(shù)據(jù)頁(yè)更改記錄。當(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)?redo log記錄的是數(shù)據(jù)頁(yè)的物理變化，因此恢復(fù)的時(shí)候速度比邏輯日志(如 binlog )要快很多。
重啟innodb 時(shí)，首先會(huì)檢查磁盤(pán)中數(shù)據(jù)頁(yè)的 LSN ，如果數(shù)據(jù)頁(yè)的LSN 小于日志中的 LSN ，則會(huì)從 checkpoint 開(kāi)始恢復(fù)。
還有一種情況，在宕機(jī)前正處于checkpoint 的刷盤(pán)過(guò)程，且數(shù)據(jù)頁(yè)的刷盤(pán)進(jìn)度超過(guò)了日志頁(yè)的刷盤(pán)進(jìn)度，此時(shí)會(huì)出現(xiàn)數(shù)據(jù)頁(yè)中記錄的 LSN 大于日志中的 LSN，這時(shí)超出日志進(jìn)度的部分將不會(huì)重做，因?yàn)檫@本身就表示已經(jīng)做過(guò)的事情，無(wú)需再重做。
redo log與binlog區(qū)別
由 binlog 和 redo log 的區(qū)別可知：binlog 日志只用于歸檔，只依靠 binlog 是沒(méi)有 crash-safe 能力的。
但只有 redo log 也不行，因?yàn)?redo log 是 InnoDB特有的，且日志上的記錄落盤(pán)后會(huì)被覆蓋掉。因此需要 binlog和 redo log二者同時(shí)記錄，才能保證當(dāng)數(shù)據(jù)庫(kù)發(fā)生宕機(jī)重啟時(shí)，數(shù)據(jù)不會(huì)丟失。
推薦下自己做的 Spring Cloud 的實(shí)戰(zhàn)項(xiàng)目：
https://github.com/YunaiV/onemall
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)。
同時(shí)， undo log 也是 MVCC(多版本并發(fā)控制)實(shí)現(xiàn)的關(guān)鍵。
關(guān)注公眾號(hào)【Java技術(shù)江湖】后回復(fù)“PDF”即可領(lǐng)取200+頁(yè)的《Java工程師面試指南》
強(qiáng)烈推薦，幾乎涵蓋所有Java工程師必知必會(huì)的知識(shí)點(diǎn)，不管是復(fù)習(xí)還是面試，都很實(shí)用。
