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

目錄

• 前言
• 【undo log】
  
• 【redo log】
  
• 【binlog】
  
• 總結

前言

MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進制日志（binlog）、錯誤日志（errorlog）、慢查詢日志（slow query log）、一般查詢日志（general log），中繼日志（relay log）。

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

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

【undo log】

事務開始之前，將當前事務版本生成 undo log（Tips：undo log 也會產生 redo log 來保證 undo log 的可靠性）。

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

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

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

id	name
1	xiaoming

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

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

【redo log】

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

• 因為Innodb是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數(shù)據(jù)頁里面的幾個字節(jié)，這個時候將完整的數(shù)據(jù)頁刷到磁盤的話，太浪費資源了！
• 一個事務可能涉及修改多個數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機IO寫入性能太差！

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

【binlog】

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

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

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

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

1. 記錄此次更新前數(shù)據(jù)記錄的快照現(xiàn)場（即寫undo log）
2. 讀取此次更新所需要的數(shù)據(jù)入內存
3. 在內存中更新數(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ā)現(xiàn)redo log中并無未完成的記錄，故障恢復后只需要回滾undo log恢復現(xiàn)場即可；

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

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

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

總結

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