本文分享自華為雲社區《面試必問 | 聊聊MySQL三大核心日誌的實現原理？》，作者：冰 河。 MySQL幾乎成為互聯網行業使用的最多的開源關係型資料庫，正因如此，MySQL也成為各大互聯網公司面試中必問的資料庫，尤其是MySQL中的事務實現機制和三大核心日誌的實現原理。 今天，我們就重點聊聊MySQ ...
本文分享自華為雲社區《面試必問 | 聊聊MySQL三大核心日誌的實現原理？》，作者：冰 河。
MySQL幾乎成為互聯網行業使用的最多的開源關係型資料庫，正因如此，MySQL也成為各大互聯網公司面試中必問的資料庫，尤其是MySQL中的事務實現機制和三大核心日誌的實現原理。
今天，我們就重點聊聊MySQL三大核心日誌的實現原理。
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）機制。
為了方便大家理解，這裡，我將MVCC的具體實現進行了簡化，後續會單獨寫一篇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文件的內容是以順序迴圈的方式寫入文件的，寫滿時就會回到第一個文件，進行覆蓋寫。
說起MySQL的日誌，有三種類型的日誌對於MySQL來說是至關重要的，這三種日誌分別為：Binlog、Undo Log 和 Redo Log。
由於Binlog和UndoLog有類似的地方，所以，我們按照如下順序依次介紹MySQL中的三大日誌原理：Undo Log——> Redo Log ——> Binlog。
- 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的使用場景可以參見冰河出版的《深入理解分散式事務：原理與實戰》與《MySQL技術大全：開發、優化和運維實戰》一書。
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文件會自動清除。
