Mysql的undo、redo、binlog，它們什么關(guān)系？
Mysql的undo、redo、binlog的區(qū)別
| 與不同引擎的關(guān)系 | 核心作用 | 生命周期 | 日志類型 | |
| undo log | 屬于innodb引擎獨(dú)有 | 回滾，保證事務(wù)的“原子性”，事務(wù)日志 | 事務(wù)開始前，以類似“快照”的方式記錄現(xiàn)場 | 邏輯日志 |
| redo log | 屬于innodb引擎獨(dú)有 | 重做，保證事務(wù)的“持久性”，事務(wù)日志 | 事務(wù)開始后記錄，prepare階段落盤 | 物理日志 |
| binlog | 工作在mysql的Server層，與使用哪種引擎無關(guān) | 實(shí)現(xiàn)主從節(jié)點(diǎn)數(shù)據(jù)的復(fù)制 | 事務(wù)執(zhí)行期間記錄，commit階段完成前落盤 | 邏輯日志 |
物理日志：記錄的是"在某個(gè)數(shù)據(jù)頁上做了什么修改"
邏輯日志：記錄的是這個(gè)語句的原始邏輯，也就是sql語句，比如"給ID=2這一行的c字段加1 "
【undo log】
事務(wù)開始之前，將當(dāng)前事務(wù)版本生成 undo log（Tips：undo log 也會產(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表中原記錄如下：
| 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ù)的持久性的呢？最簡單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。但是這么做會有嚴(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ù)的持久性、原子性呢？概述如下：
記錄此次更新前數(shù)據(jù)記錄的快照現(xiàn)場（即寫undo log）
讀取此次更新所需要的數(shù)據(jù)入內(nèi)存
在內(nèi)存中更新數(shù)據(jù)（效率高）
寫redo log，并置redo log狀態(tài)為prepare
寫binlog
置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)，表示過程全部正常完成，則什么都不需要做
作者 | 呼延灼
來源 | cnblogs.com/lucky815/p/15201475.html
