本篇文章給大家帶來了關于mysql的相關知識，其中主要介紹了關于日志的相關問題，Mysql的日志系統是Mysql保證無論何時崩潰數據都不會丟失的關鍵，下面一起來看一下，希望對大家有幫助。

程序員必備接口測試調試工具：立即使用
Apipost = Postman + Swagger + Mock + Jmeter
Api設計、調試、文檔、自動化測試工具
后端、前端、測試，同時在線協作，內容實時同步

推薦學習：mysql視頻教程

Mysql的日志系統是Mysql保證無論何時崩潰數據都不會丟失的關鍵

眾所周知Mysql是持久化的數據庫, 所有的數據都是持久化到硬盤中的, 保證數據不會丟失

Mysql保證數據不會丟失是從以下兩個方面來體現的

• 能夠恢復到任意時刻的數據狀態

• 無論在事務提交前還是提交后崩潰都能保證數據不丟失

事務過程中崩潰能夠恢復到事務提交前的狀態

事務提交后崩潰已提交的數據不會丟失

MySQL保證以上兩個點的關鍵就是通過 undo log, redo log 和 binlog 這三個日志來實現的, 接下來將逐一介紹

undo log 回滾日志

undo log是Mysql的回滾日志, 存儲的是老版本的數據

主要作用

存儲老版本的數據

配合Read View和隱藏字段實現了Mysql的快照讀

用于在事務執行失敗的時候回滾到事務開始前的版本

undo log 有什么類型

undo log 有兩種類型

對于 insert 命令, undo log 記錄的是新增的記錄的主鍵, 在回滾的時候根據 undo log 中的主鍵去刪除對應的記錄即可

對于 update / delete 命令, undo log 記錄的是被修改的記錄的舊數據

Mysql中的每一行數據都有一個最新修改當前數據行的事務id和回滾指針這兩個字段, 當對數據行進行修改之后, undo log指針就會指向舊的這一行數據, 而新生成的這一行數據的回滾指針就會指向undo log指針當前指向的舊數據行

• Mysql為了避免undo log指針修改指向的時候出現并發問題, 在修改之前會對undo log指針增加排他鎖以保證undo log的正確寫入

undo log 什么時候刪除

undo log是用于保證事務在未提交的時候可以順利回滾到事務開始前的狀態, 當事務提交之后undo log就失去作用了, 就需要被刪除

undo log是交由Mysql中的 Purage 線程來負責刪除的, purage會定期檢查undo log中的deleted_bit 標志, 這個標志會在事務提交后被設置為true, purage 線程發現為true的記錄就會負責將其刪除

redo log 重做日志

redo log是Mysql的物理日志, 負責記錄某個數據頁執行了什么樣的操作

redo log 的作用

• 負責記錄提交的事務對數據的修改, 記錄的內容大概就是對x表的y頁z偏移做了a更新

• 讓Mysql在提交事務的時候無需等待數據持久化磁盤, 只需要將redo log持久化到磁盤就可以了

• 未清除的redo log的數量標識了未刷盤的臟頁數量

為什么提交事務是選擇持久化redo log, 而不是持久化數據到磁盤

持久化數據到磁盤是隨機IO過程, 所以Mysql選擇將數據緩存起來, 等待一個合適的時機將數據一次性寫入磁盤, 減少IO

但是數據緩存在內存中有丟失的風險, 所以Mysql選擇將redo log持久化

redo log是順序寫, 持久化的效率比隨機寫的效率要高, 并且redo log記錄了數據的變化情況, 只要redo log在就可以保證在Mysql重啟后恢復數據

在InnoDB中, redo log是一個固定大小的類似循環隊列的存在, 每次寫入都從后面write pos的位置, 在持久化數據的時候就移動check point往前讀取

這樣設計的原因是因為redo log是防止Mysql崩潰后緩存的臟頁數據丟失而存在的

當Mysql中的數據被持久化到磁盤中后, 被持久化部分的redo log其實就沒有用了, 就可以騰出空間來記錄新的數據

undo log 和 redo log 的區別

undo log記錄的是事務執行過程中舊數據的狀態, redo log記錄的是數據更新之后的狀態

redo log其實保障的是事務的持久性和一致性，而undo log則保障了事務的原子性

binlog 歸檔日志

binlog是Mysql server層實現的日志, 是所有引擎通用的

作用

binlog記錄的是mysql原始的語句邏輯, 并且是采用追加寫入的形式記錄的, 所以可以用于恢復mysql在任意時刻的數據庫數據狀態

所以叫binlog是歸檔日志

同時binlog也是Mysql實現主從復制的依賴, 從庫通過從主庫中復制binlog回放來同步主庫的數據狀態

定義

先寫日志到磁盤中, 再寫數據到磁盤中Mysql的寫操作不是立刻寫入到磁盤中的, 而是先寫日志, 保證redo log和binlog都持久化到磁盤中再由后臺線程選擇時機將數據持久化到硬盤的

為什么要先寫日志到磁盤中

因為刷臟頁是一個隨機讀寫的過程, 持久化到磁盤中的速度肯定沒有redo log | binlog這些順序寫的速度快, 所以選擇先在內存中對數據進行修改, 再后期選擇時機異步持久化到磁盤中

所以在臟頁還未刷入磁盤中的這段時間就由redo log | binlog來保證數據的持久化, 防止斷電重啟等情況內存中的數據丟失

當臟頁滿的時候需要將臟頁寫入到磁盤再淘汰, 為何不全部淘汰掉下次使用的時候再通過redo log來恢復呢

從性能方面考慮的, 如果每次從磁盤中讀取數據到內存都需要和redo log比對更新, 效率很低

MySQL刷臟頁寫入到磁盤保證了數據頁只要在內存中, 就肯定是當前最新的數據可以返回

如果內存中沒有數據只要從磁盤中讀取肯定能得到最新的正確數據, 而不用再去同redo log進行比對

binlog和redo log的寫入過程 – WAL機制的基本保證

binlog和redo log都是將日志寫入劃分為三個過程 寫入cache, write和sync

在事務執行過程中會將binlog和redo log寫入到對應分配的緩存中, 以便在事務提交的時候一次性寫入到磁盤中

在事務提交的時候會先進行write將數據寫入到操作系統的頁緩存中, 此時數據還未真正寫入文件, 但是已經是交由操作系統的緩存來保管了, 如果此時Mysql進程崩潰這部分寫入的數據也不會丟失, 操作系統的內核線程會負責將這部分緩存中的數據寫入磁盤

• 但是如果操作系統崩潰了這部分數據就丟失了

最后就是mysql手動調用sync將寫入在頁緩存中的數據持久化到硬盤, 寫入完成后數據就是持久化成功了

最后的write和sync步驟mysql提供了對應的參數來控制寫入策略

redo log是通過innodb_flush_log_at_trx_commit來控制的

• 設置為 0 的時候，表示每次事務提交時都只是把redo log留在redo log的緩存中

丟失風險最大

• 設置為 1 的時候，表示每次事務提交時都將redo log直接持久化到磁盤

丟失風險最小, 但是IO占用大

• 設置為 2 的時候，表示每次事務提交時都只是把redo log寫到page cache

IO占用居中, 將寫入到磁盤這個最占用IO的過程交由操作系統來負責

binlog是通過參數sync_binlog來控制的

• sync_binlog=0 的時候，表示每次提交事務都只 write，不 fsync

• sync_binlog=1 的時候，表示每次提交事務都會執行 fsync

• sync_binlog=N(N>1) 的時候，表示每次提交事務都 write，但累積 N 個事務后才 fsync

兩階段日志提交

什么是兩階段日志提交

將redo log日志提交的過程分為prepare和commit這兩個階段, binlog日志提交在這兩個階段中間

事務提交時redo log先提交后進入prepare狀態, 然后binlog提交完成后redo log才能將日志的狀態修改為commit已提交

為什么需要兩階段日志提交

和InnoDB引擎的回滾機制有關, InnoDB的redo log提交了事務就無法回滾了, 如果在redo log提交后binlog寫入失敗的話就會出現兩份不統一的情況

如果此時數據庫異常重啟的話要依據那一份來恢復數據就值得思考了, 所以才需要兩階段日志提交

假設現在在時刻A數據庫崩潰的話, 因為binlog還未寫入, redo log還未提交, 所以重啟后事務會回滾, 兩份日志依舊是統一狀態

如果是時間段B的話, 就需要對redo log的提交標志進行判斷了, 在查詢redo log中是否有commit提交標志, 如果有的話事務沒有問題, 直接提交

• 如果redo log中沒有對應事務的提交標志的話會對binlog進行檢查

• 如果binlog完整并且帶有commit標志, 就會提交事務并在redo log后面補上commit標志如果binlog不完整就回滾事務

這里可以發現兩階段日志提交中發生了崩潰是依據binlog來進行標準判斷的, 原因是因為主從復制是依據binlog來進行的

如果對兩份日志都需要檢查完整性的話, 主庫掛掉切換到從庫的時間會變長, 以binlog為基準的話主庫掛了直接拿著binlog去從庫恢復數據即可, 無需檢查redo log的完整性

此外binlog是Mysql Server層的通用日志, 這也是選擇binlog作為基準的原因

兩階段日志提交的缺點

• 磁盤IO次數高

在提交日志的時候會有redo log和binlog對應的刷盤操作, IO次數高

• 鎖競爭激烈

為了保證多個事務提交的時候日志的記錄和事務的提交順序是一致的, 會使用鎖來保證日志提交的相對順序

但是在并發量大的情況下性能會變差

組提交機制

組提交機制的作用

當有躲過事務提交的時候, 將多個事務的日志合并在一起去寫入, 減少磁盤IO操作

組提交機制的實現

組提交機制將commit過程拆分成三個過程, 對每個過程都維護了一個隊列, 并且通過鎖來保證事務的寫入順序

• 分成三個階段分別加鎖可以減少鎖粒度, 無需鎖住事務的整個提交過程

當隊列為空的時候第一個進入隊列的事務會成為后續進入的事務的領導者, 帶領后續事務完成接下來的階段操作

階段一 : flush階段 : 多個事務按進入的順序將binlog從cache中寫入文件 (不刷盤)

第一個進入flush階段的事務會作為領導者領導后面進入的事務

領導者事務會帶領所有的事務對 redo log 進行一次 write + fsync, 也就是將redo log 寫入磁盤, 完成redo log 的propare階段

如果在這個階段Mysql崩潰了, 會在重啟后回滾這組事務

階段二 : sync : 對binlog文件做fsync操作 (將多個事務的binlog合并一起刷盤)

在flush階段將binlog寫入到binlog文件后, 會等待一段時間再進行刷盤, 目的是組合