[[385356]]

作者個人研發的在高并發場景下，提供的簡單、穩定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業提供了精準定時調度方案，經受住了生產環境的考驗。為使更多童鞋受益，現給出開源框架地址：https://github.com/sunshinelyz/mykit-delay

寫在前面

周末，我與阿里P9資深技術專家(這里就不說名字了)，聊起了MySQL這個話題，為啥會聊這個呢?因為他看到我出版了一部《MySQL技術大全：開發、優化與運維實戰》，對書籍的評價也是不錯的。隨后，我們聊了關于MySQL的幾個話題，其中一個就是MySQL的日志機制。今天，我就把大概聊的一些內容以書面文章的形式分享給大家。希望能夠為小伙伴們帶來實質性的幫助!

文章已收錄到：

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

MySQL日志

說起MySQL的日志，有三種類型的日志對于MySQL來說是至關重要的，這三種日志分別為：Binlog、Undo Log 和 Redo Log。

由于Binlog和UndoLog有類似的地方，所以，我們按照如下順序依次介紹MySQL中的三大日志原理：Undo Log——> Redo Log ——> Binlog。

Undo Log日志

什么是Undo Log

顧名思義，Undo Log的字面意思就是撤銷操作的日志，指的是使MySQL中的數據回到某個狀態。

在MySQL數據庫中，事務開始之前，MySQL會將待修改的記錄保存到Undo Log中，如果數據庫崩潰或者事務需要回滾時，MySQL可以通過利用Undo Log日志，將數據庫中的數據回滾到之前的狀態。

MySQL新增、修改和刪除數據時，在事務開始前，就會將信息寫入Undo Log中。事務提交時，并不會立刻刪除Undo Log， InnoDB存儲引擎會將事務對應的Undo Log放入待刪除列表中，之后會通過后臺的purge thread對待刪除的列表進行刪除處理。這里，值得注意的是：Undo Log是一種 邏輯日志， 記錄的是一個變化過程。比如，MySQL執行一個delete操作，Undo Log就會記錄一個insert操作;MySQL執行一個insert操作，Undo Log就會記錄一個delete操作;MySQL執行一個update操作，Undo Log就會記錄一個相反的update操作。

Undo Log以段的方式來管理和記錄日志信息，在InnoDB存儲引擎的數據文件中，包含了一種叫做rollback segment的回滾段，其內部包含了1024個undo log senment。

Undo Log作用

Undo Log對于MySQL實現事務來說，起著至關重要的作用，它實現了事務的原子性和多版本并發控制，也就是我們經常說的MVCC。

• 實現事務的原子性

Undo Log能夠實現MySQL事務的原子性，在事務的處理過程中，如果MySQL出現了錯誤或者用戶手動執行了事務的回滾操作(執行了rollback操作)，MySQL可以利用Undo Log日志將數據庫中的數據恢復到之前的狀態。

• 實現MVCC機制

Undo Log在MySQL的InnoDB存儲引擎中實現了多版本并發控制(MVCC)機制。事務未提交前，Undo Log保存了未提交之前的版本數據，Undo Log中的數據可以作為舊版本數據的副本或者快照以便其他并發事務進行讀取操作。

事務A手動開啟事務后，對goods數據表中id為1的數據進行更新操作，首先會把更新命中的數據寫入到Undo Buffer中。在事務A未提交之前，此時，事務B手動開啟事務，對goods數據表中的id為1的數據進行查詢操作，此時的事務B會讀取Undo Log中的數據并返回給客戶端，這就是MySQL中的MVCC機制。

可以在MySQL中通過下面的命令來查看控制Undo Log日志的參數。

show variables like '%innodb_undo%'; 

Redo Log日志

說了MySQL中的Undo Log，我們再來看看MySQL中的Redo Log日志。

什么是Redo Log

顧名思義Redo Log的字面意思就是重做日志，指的是在數據庫出現意外情況時能夠對重新執行某種操作。在MySQL中，事務中修改的任何數據，都會將最新的數據寫入Redo Log中進行備份。

在MySQL中，隨著事務操作的執行，就會產生Redo Log日志，在事務提交時會產生Redo Log并將其寫入Redo Buffer，Redo Buffer也并不是隨著事務的提交就會被立刻寫入到磁盤中，而是等事務操作的臟頁寫入到磁盤之后，Redo Log的使命也就完成了，此時，Redo Log日志占用的空間可以重新利用，會被后續產生的Redo Log日志覆蓋。

Redo Log的原理

Redo Log 能夠實現事務的持久性，防止在發生故障的時間點，有臟頁未寫入表的 ibd 文件中，在重啟 MySQL 服務的時候，根據 Redo Log 進行重做，從而將未提交的事務進行持久化。這個過程可以簡化為下圖所示。

Redo Log的寫機制

Redo Log文件的內容是以順序循環的方式寫入文件的，寫滿時就會回到第一個文件，進行覆蓋寫。

• Write Pos 是當前記錄的位置，一邊寫一邊后移，寫到最后一個文件末尾后就回到 0 號文件開頭;
• CheckPoint是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數 據文件;

Write Pos 和 CheckPoint之間還空著的部分，可以用來記錄新的操作。如果 Write Pos 追上 CheckPoint，表示已經寫滿，此時就需要向后移動CheckPoint來擦除數據。

每個InnoDB存儲引擎至少有1個重做日志文件組(group)，每個文件組至少有2個重做日志文件，默認為ib_logfile0和ib_logfile1 。

可以在MySQL中通過如下命令來查看控制Redo Log的參數。

show variables like '%innodb_log%'; 

Redo Log寫入機制

在Redo Log日志信息從Redo Buffer持久化到Redo Log時，具體的持久化策略可以通過innodb_flush_log_at_trx_commit 參數進行設置，具體策略如下所示。

• 0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丟失一秒內的事務數據。由后臺Master線程每隔 1秒執行一次操作。
• 1(默認值)：每次事務提交執行 Redo Buffer -> OS cache -> flush cache to disk，這種方式最安全，性能最差。
• 2：每次事務提交執行 Redo Buffer -> OS cache，然后由后臺Master線程再每隔1秒執行OS cache -> flush cache to disk 的操作。

一般建議選擇取值2，因為 MySQL 掛了數據沒有損失，整個服務器掛了才會損失1秒的事務提交數據。

Binlog日志

什么是Binlog

Binlog記錄所有MySQL數據庫表結構變更以及表數據修改的二進制日志，不會記錄select和show這類查詢操作的日志。Binlog日志是以事件形式記錄，還包含語句所執行的消耗時間。開啟Binlog日志有以下兩個最重要的使用場景。

• 主從復制：在主庫中開啟Binlog功能，這樣主庫就可以把Binlog傳遞給從庫，從庫拿到Binlog后實現數據恢復達到主從數據一致性。
• 數據恢復：通過mysqlbinlog等工具來恢復數據

Binlog文件記錄模式

Binlog文件記錄模式有STATEMENT、ROW和MIXED三種，具體含義如下。

ROW模式

ROW(row-based replication, RBR)：日志中會記錄每一行數據被修改的情況，然后在slave端對相同的數據進行修改。

優點：能清楚記錄每一個行數據的修改細節，能完全實現主從數據同步和數據的恢復。

缺點：批量操作，會產生大量的日志，尤其是alter table會讓日志暴漲。

STATMENT模式

STATMENT(statement-based replication, SBR)：每一條被修改數據的SQL都會記錄到master的Binlog中，slave在復制的時候SQL進程會解析成和原來master端執行過的相同的SQL再次執行。簡稱SQL語句復制。

優點：日志量小，減少磁盤IO，提升存儲和恢復速度

缺點：在某些情況下會導致主從數據不一致，比如last_insert_id()、now()等函數。

MIXED模式

MIXED(mixed-based replication, MBR)：以上兩種模式的混合使用，一般會使用STATEMENT模式保存binlog，對于STATEMENT模式無法復制的操作使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇寫入模式 。

Binlog文件結構

對于MySQL的Binlog文件結構有三種版本，見下圖。

關于Binlog文件結構的具體信息，小伙伴們可以參考MySQL的官方文檔，具體鏈接為：https://dev.mysql.com/doc/internals/en/event-header-fields.html

Binlog寫機制

根據記錄模式和操作觸發event事件生成log event(事件觸發執行機制)。

將事務執行過程中產生的日志時間(log event)寫入緩沖區，每個事務線程都有一個緩沖區。Log Event保存在一個binlog_cache_mngr數據結構中，在該結構中有兩個緩沖區，一個是stmt_cache，用于存放不支持事務的信息;另一個是trx_cache，用于存放支持事務的信息。

事務在提交階段會將產生的log event寫入到外部binlog文件中。不同事務以串行方式將log event寫入Binlog文件中，所以一個事務包含的log event信息在binlog文件中是連續的，中間不會插入其他事務的log event。

Binlog文件操作

Binlog狀態查看

show variables like 'log_bin'; 

開啟Binlog功能，需要修改my.cnf或my.ini配置文件，在[mysqld]下面增加log_bin=mysql_bin_log，重啟 MySQL服務。

binlog-format=ROW 
log-bin=mysqlbinlog 

使用show binlog events命令

show binary logs; //等價于show master logs; 
show master status; 
show binlog events; 
show binlog events in 'mysqlbinlog.000001'; 

使用mysqlbinlog 命令

mysqlbinlog "文件名" 
mysqlbinlog "文件名" > "test.sql" 

使用 binlog 恢復數據

//按指定時間恢復 
mysqlbinlog --start-datetime="2021-02-28 18:00:00" --stopdatetime="2021-03-01 00:00:00" mysqlbinlog.000001 | mysql -uroot -p123456 
//按事件位置號恢復 
mysqlbinlog --start-position=1789 --stop-position=2674 mysqlbinlog.000001 
| mysql -uroot -p123456 

刪除Binlog文件

purge binary logs to 'mysqlbinlog.000001'; //刪除指定文件 
purge binary logs before '2021-03-01 00:00:00'; //刪除指定時間之前的文件 
reset master; //清除所有文件 

可以通過設置expire_logs_days參數來啟動自動清理功能。默認值為0表示沒啟用。設置為大于0的整數表示超出多少天binlog文件會自動清除。

本文轉載自微信公眾號「冰河技術」，可以通過以下二維碼關注。轉載本文請聯系冰河技術公眾號。