[[385356]]

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

寫在前面

周末，我與阿里P9資深技術專家(這里就不說名字了)，聊起了MySQL這個話題，為啥會聊這個呢?因為他看到我出版了一部《MySQL技術大全：開發(fā)、優(yōu)化與運維實戰(zhàn)》，對書籍的評價也是不錯的。隨后，我們聊了關于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中的數(shù)據(jù)回到某個狀態(tài)。

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

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

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

Undo Log作用

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

• 實現(xiàn)事務的原子性

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

• 實現(xiàn)MVCC機制

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

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

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

show variables like '%innodb_undo%'; 

Redo Log日志

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

什么是Redo Log

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

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

Redo Log的原理

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

Redo Log的寫機制

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

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

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

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

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

show variables like '%innodb_log%'; 

Redo Log寫入機制

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

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

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

Binlog日志

什么是Binlog

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

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

Binlog文件記錄模式

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

ROW模式

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

優(yōu)點：能清楚記錄每一個行數(shù)據(jù)的修改細節(jié)，能完全實現(xiàn)主從數(shù)據(jù)同步和數(shù)據(jù)的恢復。

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

STATMENT模式

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

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

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

MIXED模式

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

Binlog文件結構

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

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

Binlog寫機制

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

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

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

Binlog文件操作

Binlog狀態(tài)查看

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 恢復數(shù)據(jù)

//按指定時間恢復 
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參數(shù)來啟動自動清理功能。默認值為0表示沒啟用。設置為大于0的整數(shù)表示超出多少天binlog文件會自動清除。

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