必須了解的mysql三大日志-binlog、redo log和undo log
來源：https://juejin.im/post/6860252224930070536
日志是?mysql?數(shù)據(jù)庫的重要組成部分，記錄著數(shù)據(jù)庫運行期間各種狀態(tài)信息。mysql日志主要包括錯誤日志、查詢?nèi)罩尽⒙樵內(nèi)罩尽⑹聞?wù)日志、二進(jìn)制日志幾大類。作為開發(fā)，我們重點需要關(guān)注的是二進(jìn)制日志(?binlog?)和事務(wù)日志(包括redo log?和?undo log?)，本文接下來會詳細(xì)介紹這三種日志。
binlog
binlog?用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進(jìn)制的形式保存在磁盤中。binlog?是?mysql的邏輯日志，并且由?Server?層進(jìn)行記錄，使用任何存儲引擎的?mysql?數(shù)據(jù)庫都會記錄?binlog?日志。
邏輯日志：可以簡單理解為記錄的就是sql語句 。
物理日志：
mysql?數(shù)據(jù)最終是保存在數(shù)據(jù)頁中的，物理日志記錄的就是數(shù)據(jù)頁變更 。
binlog?是通過追加的方式進(jìn)行寫入的，可以通過?max_binlog_size?參數(shù)設(shè)置每個?binlog
文件的大小，當(dāng)文件大小達(dá)到給定值之后，會生成新的文件來保存日志。
binlog使用場景
在實際應(yīng)用中，?binlog?的主要使用場景有兩個，分別是?主從復(fù)制?和?數(shù)據(jù)恢復(fù)。
主從復(fù)制?：在?
Master?端開啟?binlog?，然后將?binlog?發(fā)送到各個Slave?端，?Slave?端重放?binlog?從而達(dá)到主從數(shù)據(jù)一致。數(shù)據(jù)恢復(fù)?：通過使用?
mysqlbinlog?工具來恢復(fù)數(shù)據(jù)。
binlog刷盤時機
對于?InnoDB?存儲引擎而言，只有在事務(wù)提交時才會記錄?biglog?，此時記錄還在內(nèi)存中，那么?biglog
是什么時候刷到磁盤中的呢？mysql?通過?sync_binlog?參數(shù)控制?biglog?的刷盤時機，取值范圍是?0-N
：
0：不去強制要求，由系統(tǒng)自行判斷何時寫入磁盤；
1：每次?
commit?的時候都要將?binlog?寫入磁盤；N：每N個事務(wù)，才會將?
binlog?寫入磁盤。
從上面可以看出，?sync_binlog?最安全的是設(shè)置是?1?，這也是?MySQL 5.7.7
之后版本的默認(rèn)值。但是設(shè)置一個大一些的值可以提升數(shù)據(jù)庫性能，因此實際情況下也可以將值適當(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?)，每一條會修改數(shù)據(jù)的sql語句會記錄到?binlog?中 ?。優(yōu)點：不需要記錄每一行的變化，減少了 binlog 日志量，節(jié)約了? IO ?, 從而提高了性能；
缺點：在某些情況下會導(dǎo)致主從數(shù)據(jù)不一致，比如執(zhí)行sysdate()?、 ?slepp() ?等 。
ROW：基于行的復(fù)制(row-based replication, RBR?)，不記錄每條sql語句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了 。優(yōu)點：不會出現(xiàn)某些特定情況下的存儲過程、或function、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題 ；
缺點：會產(chǎn)生大量的日志，尤其是` alter table ` 的時候會讓日志暴漲
MIXED：基于STATMENT?和?ROW?兩種模式的混合復(fù)制(?mixed-based replication, MBR?)，一般的復(fù)制使用?STATEMENT?模式保存?binlog?，對于?STATEMENT?模式無法復(fù)制的操作使用?ROW?模式保存?binlog
redo log
為什么需要redo log
我們都知道，事務(wù)的四大特性里面有一個是?持久性?，具體來說就是
只要事務(wù)提交成功，那么對數(shù)據(jù)庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態(tài)?。那么?mysql
是如何保證一致性的呢？最簡單的做法是在每次事務(wù)提交的時候，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。但是這么做會有嚴(yán)重的性能問題，主要體現(xiàn)在兩個方面：
因為?
Innodb?是以?頁?為單位進(jìn)行磁盤交互的，而一個事務(wù)很可能只修改一個數(shù)據(jù)頁里面的幾個字節(jié)，這個時候?qū)⑼暾臄?shù)據(jù)頁刷到磁盤的話，太浪費資源了！一個事務(wù)可能涉及修改多個數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機IO寫入性能太差！
因此?mysql?設(shè)計了?redo log?，?具體來說就是只記錄事務(wù)對數(shù)據(jù)頁做了哪些修改
，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。
redo log基本概念
redo log?包括兩部分：一個是內(nèi)存中的日志緩沖(?redo log buffer?)，另一個是磁盤上的日志文件(?redo log file?)。mysql?每執(zhí)行一條?DML?語句，先將記錄寫入?redo log buffer
，后續(xù)某個時間點再一次性將多個操作記錄寫到?redo log file?。這種?先寫日志，再寫磁盤?的技術(shù)就是?MySQL
里經(jīng)常說到的?WAL(Write-Ahead Logging)?技術(shù)。
在計算機操作系統(tǒng)中，用戶空間(?user space?)下的緩沖區(qū)數(shù)據(jù)一般情況下是無法直接寫入磁盤的，中間必須經(jīng)過操作系統(tǒng)內(nèi)核空間(?kernel space?)緩沖區(qū)(OS Buffer?)。因此，?redo log buffer?寫入?redo log file?實際上是先寫入?OS Buffer?，然后再通過系統(tǒng)調(diào)用?fsync()?將其刷到?redo log file
中，過程如下：
mysql?支持三種將?redo log buffer?寫入?redo log file?的時機，可以通過?innodb_flush_log_at_trx_commit?參數(shù)配置，各參數(shù)值含義如下：
| 參數(shù)值 | 含義 |
|---|---|
| 0（延遲寫） | 事務(wù)提交時不會將?redo log buffer?中日志寫入到?os buffer?，而是每秒寫入?os buffer?并調(diào)用?fsync()?寫入到?redo log file?中。也就是說設(shè)置為0時是(大約)每秒刷新寫入到磁盤中的，當(dāng)系統(tǒng)崩潰，會丟失1秒鐘的數(shù)據(jù)。 |
| 1（實時寫，實時刷） | 事務(wù)每次提交都會將?redo log buffer?中的日志寫入?os buffer并調(diào)用?fsync()?刷到?redo log file?中。這種方式即使系統(tǒng)崩潰也不會丟失任何數(shù)據(jù)，但是因為每次提交都寫入磁盤，IO的性能較差。 |
| 2（實時寫，延遲刷） | 每次提交都僅寫入到?os buffer?，然后是每秒調(diào)用?fsync()?將?os buffer中的日志寫入到?redo log file?。 |
redo log記錄形式
前面說過，?redo log?實際上記錄數(shù)據(jù)頁的變更，而這種變更記錄是沒必要全部保存，因此?redo log
實現(xiàn)上采用了大小固定，循環(huán)寫入的方式，當(dāng)寫到結(jié)尾時，會回到開頭循環(huán)寫日志。如下圖：
同時我們很容易得知， 在innodb中，既有redo log?需要刷盤，還有?數(shù)據(jù)頁?也需要刷盤，?redo log存在的意義主要就是降低對?數(shù)據(jù)頁?刷盤的要求 ** 。在上圖中，?write pos?表示?redo log?當(dāng)前記錄的?LSN?(邏輯序列號)位置，check point?表示?數(shù)據(jù)頁更改記錄?刷盤后對應(yīng)?redo log?所處的?LSN(邏輯序列號)位置。write pos?到?check point?之間的部分是?redo log?空著的部分，用于記錄新的記錄；check point?到?write pos?之間是?redo log?待落盤的數(shù)據(jù)頁更改記錄。當(dāng)?write pos追上?check point?時，會先推動?check point?向前移動，空出位置再記錄新的日志。
啟動?innodb?的時候，不管上次是正常關(guān)閉還是異常關(guān)閉，總是會進(jìn)行恢復(fù)操作。因為?redo log記錄的是數(shù)據(jù)頁的物理變化，因此恢復(fù)的時候速度比邏輯日志(如?binlog?)要快很多。重啟?innodb?時，首先會檢查磁盤中數(shù)據(jù)頁的?LSN，如果數(shù)據(jù)頁的?LSN?小于日志中的?LSN?，則會從?checkpoint?開始恢復(fù)。還有一種情況，在宕機前正處于checkpoint?的刷盤過程，且數(shù)據(jù)頁的刷盤進(jìn)度超過了日志頁的刷盤進(jìn)度，此時會出現(xiàn)數(shù)據(jù)頁中記錄的?LSN?大于日志中的?LSN
，這時超出日志進(jìn)度的部分將不會重做，因為這本身就表示已經(jīng)做過的事情，無需再重做。
redo log與binlog區(qū)別
| redo log | binlog | |
|---|---|---|
| 文件大小 | redo log?的大小是固定的。 | binlog?可通過配置參數(shù)?max_binlog_size?設(shè)置每個binlog?文件的大小。 |
| 實現(xiàn)方式 | redo log?是?InnoDB?引擎層實現(xiàn)的，并不是所有引擎都有。 | binlog?是?Server?層實現(xiàn)的，所有引擎都可以使用?binlog?日志 |
| 記錄方式 | redo log 采用循環(huán)寫的方式記錄，當(dāng)寫到結(jié)尾時，會回到開頭循環(huán)寫日志。 | binlog通過追加的方式記錄，當(dāng)文件大小大于給定值后，后續(xù)的日志會記錄到新的文件上 |
| 適用場景 | redo log?適用于崩潰恢復(fù)(crash-safe) | binlog?適用于主從復(fù)制和數(shù)據(jù)恢復(fù) |
由?binlog?和?redo log?的區(qū)別可知：binlog?日志只用于歸檔，只依靠binlog?是沒有?crash-safe?能力的。但只有?redo log?也不行，因為?redo log?是?InnoDB
特有的，且日志上的記錄落盤后會被覆蓋掉。因此需要?binlog?和?redo log
二者同時記錄，才能保證當(dāng)數(shù)據(jù)庫發(fā)生宕機重啟時，數(shù)據(jù)不會丟失。
undo log
數(shù)據(jù)庫事務(wù)四大特性中有一個是?原子性?，具體來說就是?原子性是指對數(shù)據(jù)庫的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況
。實際上，?原子性?底層就是通過?undo log?實現(xiàn)的。undo log?主要記錄了數(shù)據(jù)的邏輯變化，比如一條?INSERT?語句，對應(yīng)一條?DELETE?的?undo log?，對于每個?UPDATE?語句，對應(yīng)一條相反的?UPDATE?的?undo log?，這樣在發(fā)生錯誤時，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)。同時，?undo log?也是?MVCC(多版本并發(fā)控制)實現(xiàn)的關(guān)鍵，這部分內(nèi)容在 ?面試中的老大難-mysql事務(wù)和鎖，一次性講清楚！中有介紹，不再贅述。
- END -
?推薦閱讀? SpringCloud微服務(wù)項目運維必知必會 5 分鐘看懂 HTTP 3 強大的 iptables 在 K8s 中的應(yīng)用剖析 Java 應(yīng)用最常見的3個問題排查思路 記一次線上商城系統(tǒng)高并發(fā)的優(yōu)化 一篇漫畫帶你了解 Linux 內(nèi)核長啥樣！ SSH只能用于遠(yuǎn)程Linux主機？那說明你見識太小了！
點亮，服務(wù)器三年不宕機
