關於MySQL日誌，我與阿里P9都聊了些啥？

寫在前面

週末，我與阿里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的使用場景能夠參見我出版的圖書《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文件會自動清除。

更多有關於Binlog日誌的信息，能夠參考我出版的《MySQL技術大全：開發、優化與運維實戰》一書。

好了，今天就到這兒吧，我是冰河，你們有啥問題能夠在下方留言，也能夠加我微信：sun_shine_lyz，我拉你進羣，一塊兒交流技術，一塊兒進階，一塊兒牛逼~~