前言

MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進(jìn)制日志（binlog）、錯(cuò)誤日志（errorlog）、慢查詢?nèi)罩荆╯low query log）、一般查詢?nèi)罩荆╣eneral log），中繼日志（relay log）。

其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進(jìn)制日志也與事務(wù)操作有一定的關(guān)系，這三種日志，對理解MySQL中的事務(wù)操作有著重要的意義。

【undo log】

事務(wù)開始之前，將當(dāng)前事務(wù)版本生成 undo log（Tips：undo log 也會(huì)產(chǎn)生 redo log 來保證 undo log 的可靠性）。

事務(wù)提交之后，undo log 并不能立馬被刪除，而是放入待清理的鏈表，由 purge 線程判斷是否有其它事務(wù)在使用 undo 段中表的上一個(gè)事務(wù)之前的版本信息，從而決定是否可以清理 undo log 的日志空間。

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

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

執(zhí)行sql  update user set name = 'xiaohong' where id = 1; 的時(shí)候生成的undo log大概是update user set name = 'xiaoming' where id = 1;

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

【redo log】

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

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

因此，mysql設(shè)計(jì)了redo log機(jī)制，并通過WAL（Write-Ahead Logging）技術(shù)進(jìn)行了性能優(yōu)化。WAL的核心就是先順序IO寫日志磁盤、再隨機(jī)IO寫數(shù)據(jù)磁盤，節(jié)省的是隨機(jī)寫磁盤的 IO 消耗。mysql 每執(zhí)行一條 DML 語句，先將記錄順序追加寫入 redo log buffer并更新內(nèi)存中的數(shù)據(jù)，等到有空閑線程、內(nèi)存不足、Redo Log滿時(shí)再批量落盤持久化。

【binlog】

binlog是mysql的邏輯日志并且由Server層進(jìn)行記錄，記錄對象為任意數(shù)據(jù)庫引擎的寫入性操作(不包括查詢)信息，以二進(jìn)制的形式保存在磁盤中。

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

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

數(shù)據(jù)更新過程中，萬一更新數(shù)據(jù)的過程中系統(tǒng)出現(xiàn)故障異常重啟了，如何保證事務(wù)的持久性、原子性呢？概述如下：

1. 記錄此次更新前數(shù)據(jù)記錄的快照現(xiàn)場（即寫undo log）
2. 讀取此次更新所需要的數(shù)據(jù)入內(nèi)存
3. 在內(nèi)存中更新數(shù)據(jù)（效率高）
4. 寫redo log，并置redo log狀態(tài)為prepare
5. 寫binlog
6. 置redo log狀態(tài)為commit　　　　　　　

基于上述簡化版的undo log、redo log和binlog的寫入流程，我們來梳理下原子性、持久性、一致性的可靠性保證：

　　A）假如是在步驟1/2/3中任一步驟發(fā)生故障，故障恢復(fù)后發(fā)現(xiàn)redo log中并無未完成的記錄，故障恢復(fù)后只需要回滾undo log恢復(fù)現(xiàn)場即可；

　　B）假如在步驟4/5中任一步驟發(fā)生故障，故障恢復(fù)后發(fā)現(xiàn)redo log處于prepare狀態(tài)，則進(jìn)一步判斷是否已經(jīng)寫入binlog：

1. 若已經(jīng)寫入binlog，則重新執(zhí)行redo log的相關(guān)記錄直到成功達(dá)到commit狀態(tài)（主從的一致性）；
2. 若未寫入binlog，則回滾undo log恢復(fù)現(xiàn)場（原子性）；　　　　　　　
   

　　C）假如在步驟6發(fā)生故障，故障恢復(fù)后發(fā)現(xiàn)redo log處于commit狀態(tài)，表示過程全部正常完成，則什么都不需要做。

總結(jié)

到此這篇關(guān)于Mysql中undo、redo與binlog區(qū)別的文章就介紹到這了,更多相關(guān)Mysql中undo、redo與binlog區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論