Undo Log

意為撤銷或取消，以撤銷操作為目的，返回指定某個狀態(tài)的操作。Undo Log 屬于邏輯日志，記錄一個變化過程。主要采用段的方式管理和記錄。在 InnoDB 數(shù)據(jù)文件中包含一種 rollback segment 回滾段（內(nèi)部包含了 1024 個 Undo Log Segment），可以通過參數(shù) innodb_undo 命令控制 Undo Log。

show variables like '%innodb_undo%';

Undo Log 在事務開始前產(chǎn)生；事務在提交時，并不會立刻刪除 Undo Log，InnoDB 會將該事務對應的 Undo Log放入到刪除列表中，后面會通過后臺線程 purge thread 進行回收處理。例如：執(zhí)行一個 delete，Undo Log 會記錄一個 insert；執(zhí)行一個 Update，Undo Log 會記錄一個相反的 Update 操作。

Undo Log 的作用

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

Undo Log 是為了實現(xiàn)事務的原子性而出現(xiàn)的產(chǎn)物。事務處理過程中，如果出現(xiàn)了錯誤或者用戶執(zhí)行了 ROLLBACK 語句，MySQL 可以利用 Undo Log 中的備份將數(shù)據(jù)恢復到事務開始之前的狀態(tài)。

• 實現(xiàn)多版本并發(fā)控制（MVCC）

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

我們看個案例，如下：

圖中可以看到，事務 A 手動開啟事務，執(zhí)行了更新操作，首先會把更新命中的數(shù)據(jù)備份到 Undo Buffer 中。事務 B 手動開啟事務，執(zhí)行了查詢操作，此時會讀取 Undo Buffer 中的日志數(shù)據(jù)并返回（進行了快照讀操作）。

Redo Log 和 Binlog

Redo Log 和 Binlog 是 MySQL 日志系統(tǒng)中非常重要的兩種機制。

Redo Log

顧名思義，就是重做，主要用于在數(shù)據(jù)庫發(fā)送意外時進行數(shù)據(jù)的恢復。

Redo Log 會隨著事務操作的執(zhí)行而生成。在事務提交的時候會將產(chǎn)生的 Redo Log 寫入到 Log Buffer 中，并不是隨著事務的提交就立刻寫入到磁盤文件。等事務操作的臟頁寫入到磁盤之后，Redo Log 的使命也就完成了，此時Redo Log 占用的空間就可以重用（被覆蓋寫入）。

Redo Log 的工作原理圖

Redo Log 寫入機制

Redo Log 的文件內(nèi)容是以存下循環(huán)的方式寫入文件中的，寫滿時則會回溯到第一個文件，進行覆蓋寫。

如圖所示：

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

Write Pos 和 Check Point 之間還空著的部分可以用來記錄新的操作。如果 Write Pos 追上 Check Point 則表示已寫滿，此時不能再繼續(xù)執(zhí)行新的更新了，需要停下來擦掉一些記錄，把 Check Point 推進一下。

Redo Log 的相關配置

每個 InnoDB 引擎至少擁有 1 個重做日志文件組（Redo Log Group），每個文件組至少有 2 個重做日志文件（Redo Log）,默認為 ib_logfile0 和 ib_logfile1。Redo Buffer 持久化到 Redo Log 的策略，可以通過參數(shù) Innodb_flush_log_at_trx_commit 設置：

Innodb_flush_log_at_trx_commit =0：

• 表示每秒提交 Redo Buffer -> OS Cache -> flush cache to disk，這個過程可能會丟失 1 秒內(nèi)的事務數(shù)據(jù)（主要由后臺的 Master 線程每隔 1 秒執(zhí)行一次操作）。

Innodb_flush_log_at_trx_commit =1：

• 表示每次事務提交執(zhí)行時，Redo Buffer -> OS Cache -> flush cache to disk，這是最安全且性能最差的方式。

Innodb_flush_log_at_trx_commit =2：

• 表示每次事務提交執(zhí)行時：Redo Buffer -> OS Cache，然后由后臺的 Master 線程每隔 1 秒執(zhí)行 OS Cache -> flush cahce to disk 的操作。

一般建議選擇取值 2 ，這樣的話 MySQL 掛了時候不會丟失數(shù)據(jù)，整個 MySQL 訪問掛了才會損失 1 秒的事務提交數(shù)據(jù)。

如圖：

Binlog 日志

Binlog 記錄模式

Redo Log 是屬于 InnoDB 引擎所特有的日志，而 MySQL Server 也有自己的日志，這個日志就是 Binary Log（二進制日志），簡稱 Binlog。

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

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

Binlog 文件名默認為“主機名_binlog-序列號”格式，例如 oak_binlog-000001，也可以在配置文件中指定名稱。文件記錄模式有 STATEMENT、ROW 和 MIXED 三種，具體含義如下：

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

• 優(yōu)點：能清楚記錄每一個行數(shù)據(jù)的修改細節(jié)，能完全實現(xiàn)主從數(shù)據(jù)同步和數(shù)據(jù)的恢復。
• 缺點：批量操作，會產(chǎn)生大量的日志，尤其是 alter table 會讓日志暴漲。

STATEMENT（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-based replication，簡稱 MBR）：以上兩種模式的混合使用，一般會使用 STATEMENT 模式保存 Binlog ，對于 STATEMENT 模式無法復制的操作使用 ROW 模式保存 Binlog，MySQL 會根據(jù)執(zhí)行的 SQL 語句選擇寫入模式。

Binlog 文件結(jié)構(gòu)

MySQL 的 Binlog 文件中記錄的是對數(shù)據(jù)庫的各種修改操作，用來表示修改操作的數(shù)據(jù)結(jié)構(gòu)是 Log Event。不同的修改操作對應著不同的 Log Event。比較常用的 log event 有：Query Event、Row Event、Xid Event 等。Binlog 文件的內(nèi)存就是各種 Log Event 的集合。

我們看下 Binlog 文件中的 Log Event 的結(jié)構(gòu)圖，如下：

Binlog 寫入機制

• 根據(jù)記錄模式和操作觸發(fā) event 事件并生成 Log Event（事件觸發(fā)執(zhí)行機制）
• 將事務執(zhí)行過程中產(chǎn)生的 Log Event 寫入緩沖區(qū)，每個事務線程都有一個緩沖區(qū)。Log Event 保存在一個 binlog_cache_mngr 數(shù)據(jù)結(jié)構(gòu)中，在該結(jié)構(gòu)中有兩個緩沖區(qū)，一個是 stmt_cache，用于存放不支持事務的消息；另一個是 trx_cache，用于存放支持事務的消息。

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

Binlog 文件操作相關命令

查看 Binlog 狀態(tài)

show variables like 'log_bin';

開啟 Binlog 功能

set global log_bin=mysqllogbin；(這里可能會報錯：ERROR 1238 （HY000）: Variable 'log_bin' is a read only variable)，這個時候需要修改 my.cnf 或 my.ini 配置文件，在 [mysqld] 下面增加 log_bin=mysql_bin_log，重啟 MYSQL 服務。

#log-bin=ON
#log-bin-basename=mysqlbinlog
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="2020-0425 18:00:00" --stop-datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234

-- 按事件位置號恢復
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234

mysqlddump：定期全部備份數(shù)據(jù)庫數(shù)據(jù)。mysqlbinlog 可以做增量備份和恢復操作。

刪除 Binlog 文件

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

可以通過設置 expire_logs_days 參數(shù)來啟動自動清理功能。默認值為 0 表示沒啟用。設置為 1 表示超出 1 天 Binlog 文件會自動刪除掉。

Redo Log 和 Binlog 區(qū)別

Redo Log 是屬于 InnoDB 引擎功能，Binlog 是屬于 MySQL Server 自帶功能，并且是以二進制文件進行記錄的。

Redo Log 屬于物理日志，記錄該數(shù)據(jù)頁更新狀態(tài)內(nèi)容，Binlog 是邏輯日志，記錄更新的過程。

Redo Log 日志是循環(huán)寫的，日志的空間大小是固定的，Binlog 是追加寫入，寫完一個寫下一個，不會覆蓋使用。

Redo Log 作為服務器異常宕機后，事務數(shù)據(jù)自動恢復使用，Binlog 可以作為主從復制和數(shù)據(jù)恢復使用。Binlog 沒有自動 crash-safe 能力。

到此這篇關于MySQL InnoDB 三大文件日志的實現(xiàn)的文章就介紹到這了,更多相關MySQL InnoDB文件日志內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論