Mysql中undo、redo與binlog的區(qū)別淺析

熱門(mén)標(biāo)簽：怎么在高德地圖標(biāo)注多個(gè)點(diǎn) AI智能云呼電話機(jī)器人怎么注冊(cè) 溫州語(yǔ)音外呼系統(tǒng)排名 百度地圖標(biāo)注信息怎么修改 商家地圖標(biāo)注圖片 沈陽(yáng)外呼系統(tǒng)有效果嗎 電話機(jī)器人接口是什么樣的 福州外呼系統(tǒng)招商 四川穩(wěn)定外呼系統(tǒng)公司

目錄

• 前言
• 【undo log】
  
• 【redo log】
  
• 【binlog】
  
• 總結(jié)

前言

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

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

	與不同引擎的關(guān)系	核心作用	生命周期	日志類(lèi)型
undo log	屬于innodb引擎獨(dú)有	回滾，保證事務(wù)的“原子性”，事務(wù)日志	事務(wù)開(kāi)始前，以類(lèi)似“快照”的方式記錄現(xiàn)場(chǎng)	邏輯日志
redo log	屬于innodb引擎獨(dú)有	重做，保證事務(wù)的“持久性”，事務(wù)日志	事務(wù)開(kāi)始后記錄，prepare階段落盤(pán)	物理日志
binlog	工作在mysql的Server層，與使用哪種引擎無(wú)關(guān)	實(shí)現(xiàn)主從節(jié)點(diǎn)數(shù)據(jù)的復(fù)制	事務(wù)執(zhí)行期間記錄，commit階段完成前落盤(pán)	邏輯日志

【undo log】

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

事務(wù)提交之后，undo log 并不能立馬被刪除，而是放入待清理的鏈表，由 purge 線程判斷是否有其它事務(wù)在使用 undo 段中表的上一個(gè)事務(wù)之前的版本信息，從而決定是否可以清理 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)。例如，user表中原記錄如下：

id	name
1	xiaoming

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

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

【binlog】

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

在實(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ù)。

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

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

基于上述簡(jiǎn)化版的undo log、redo log和binlog的寫(xiě)入流程，我們來(lái)梳理下原子性、持久性、一致性的可靠性保證：

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

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

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

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

總結(jié)

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