MySQL日志之redo log和binlog的區(qū)別是什么

這篇文章主要介紹了MySQL日志之redo log和binlog的區(qū)別是什么，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

redo log和binlog的區(qū)別

redo log

在MySQL中，如果你要更新一條語(yǔ)句，需要帶更新條件，比如update T set name = ‘god-jiang’ where id=6，一般都是先查詢到id=6的語(yǔ)句，然后再進(jìn)行更新操作。

如果更新的數(shù)量是100條，1000條甚至10000條的時(shí)候，每一次更新都需要寫到磁盤上。然后磁盤也要找到對(duì)應(yīng)的記錄，然后再更新，整個(gè)過(guò)程IO成本、查找成本太大，為了解決這個(gè)問(wèn)題，MySQL的設(shè)計(jì)者采用了WAL技術(shù)來(lái)解決。WAL全稱是Write Ahead Logging，意思就是先寫日志，再寫磁盤。

具體操作：當(dāng)有一條記錄需要更新的時(shí)候，InnoDB引擎會(huì)先把記錄寫到redo log中，并更新內(nèi)存，這個(gè)時(shí)候更新就算完成了。同時(shí)，InnoDB引擎會(huì)在適當(dāng)?shù)臅r(shí)候（系統(tǒng)空閑時(shí)），將這個(gè)操作記錄更新到磁盤中，這個(gè)更新往往是在系統(tǒng)比較空閑的時(shí)候。

但是redo log的大小是固定的，不可能一直無(wú)限寫，讓我們看下MySQL怎么做到的吧。

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

write pos與check point之間綠色的部分表示可以記錄新的操作。如果write pos追上了check point，表示redo log滿了，這個(gè)時(shí)候就不能繼續(xù)執(zhí)行新的操作，需要停下擦除一些記錄，并且把check point往后推進(jìn)。

有了redo log，InnoDB可以保證即使數(shù)據(jù)庫(kù)發(fā)現(xiàn)異常重啟了，也不會(huì)丟失之前提交的事務(wù)，這個(gè)能力也被稱為crash-safe。

以上就是redo log的介紹，看完了之后，你可以試著去問(wèn)一下你公司的DBA同事，MySQL是否可以恢復(fù)到半個(gè)月內(nèi)任意一秒的狀態(tài)，得到的答案肯定是可以的，這都要?dú)w功于redo log的功勞。

binlog

從MySQL整體來(lái)看，其實(shí)分為兩層，一層是Server層，一層是存儲(chǔ)引擎層。上面聊到的redo log就是屬于InnoDB引擎特有的日志，而binlog是屬于Server層的日志，也稱為歸檔日志。

redo log和binlog的區(qū)別

• redo log是InnoDB引擎特有的；binlog是MySQL的Server層實(shí)現(xiàn)的，所有引擎都可以使用

• redo log是物理日志，記錄的是“在XXX數(shù)據(jù)頁(yè)上做了XXX修改”；binlog是邏輯日志，記錄的是原始邏輯，其記錄是對(duì)應(yīng)的SQL語(yǔ)句

• redo log是循環(huán)寫的，空間一定會(huì)用完，需要write pos和check point搭配；binlog是追加寫，寫到一定大小會(huì)切換到下一個(gè)，并不會(huì)覆蓋以前的日志

通過(guò)簡(jiǎn)單的更新語(yǔ)句演示執(zhí)行器和InnoDB引擎的內(nèi)部流程

update T set name = 'god-jiang' where id = 6

1. 通過(guò)執(zhí)行器從InnoDB引擎取出id=6的記錄，然后加載到內(nèi)存中

2. 執(zhí)行器拿到引擎返回的結(jié)果，把name修改為’god-jiang’，再重新調(diào)用存儲(chǔ)引擎的接口寫入新數(shù)據(jù)

3. 引擎將新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個(gè)更新操作寫到redo log中，此時(shí)redo log處于prepare狀態(tài)

4. 執(zhí)行器生成這個(gè)操作的binlog，并把binlog寫到磁盤中

5. 執(zhí)行器調(diào)用引擎提交事務(wù)的接口，并且把剛剛寫入的redo log改為commit狀態(tài)，更新完成

對(duì)應(yīng)的流程圖

最后為什么寫入redo log會(huì)處于prepare狀態(tài)，然后寫入binlog還要變成commit狀態(tài)？其實(shí)這個(gè)過(guò)程就叫做“兩階段提交”。

兩階段提交

其實(shí)redo log和binlog都可以用于表示事務(wù)的提交的狀態(tài)，而兩階段提交就是讓這兩個(gè)狀態(tài)保持邏輯上的一致。

舉例子：update T set name = ‘god-jiang’ where id = 6沒(méi)有兩階段提交會(huì)發(fā)生什么？

先寫redo log后寫binlog。假設(shè)寫完了redo log，binlog還沒(méi)有寫完，這個(gè)時(shí)候MySQL異常重啟。因?yàn)閞edo log寫完了，恢復(fù)系統(tǒng)的時(shí)候name=‘god-jiang’。但是binlog沒(méi)有寫完，所以binlog沒(méi)有記錄這條語(yǔ)句，這個(gè)時(shí)候用binlog恢復(fù)數(shù)據(jù)的時(shí)候，恢復(fù)出來(lái)的name就是原來(lái)值，與redo log不同。

同理可得，先寫binlog后寫redo log也會(huì)發(fā)現(xiàn)兩個(gè)日志恢復(fù)的數(shù)據(jù)不同。這個(gè)不一致會(huì)導(dǎo)致線上出現(xiàn)主從不一致的情況。

總結(jié)

• redo log可以保存crash-safe能力，可以保證MySQL異常重啟數(shù)據(jù)不丟失

• binlog可以記錄對(duì)應(yīng)的SQL語(yǔ)句，也可以保證MySQL異常重啟數(shù)據(jù)不丟失

• 提交事務(wù)的兩階段提交，可以維持?jǐn)?shù)據(jù)邏輯一致性

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“MySQL日志之redo log和binlog的區(qū)別是什么”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!