首先，我們先來看看一次查詢/更新語句流程圖

本文會將重點放在執(zhí)行器<->存儲引擎之間的交互。

mysql不是每次數(shù)據(jù)更改都立刻寫到磁盤，而是會先將修改后的結(jié)果暫存在內(nèi)存中,當一段時間后，再一次性將多個修改寫到磁盤上，減少磁盤io成本，同時提高操作速度。

mysql通過WAL(write-ahead logging)技術(shù)保證事務(wù)：

在同一個事務(wù)中，每當數(shù)據(jù)庫進行修改數(shù)據(jù)操作時，將修改結(jié)果更新到內(nèi)存后，會在redo log添加一行記錄記錄“需要在哪個數(shù)據(jù)頁上做什么修改”，并將該記錄狀態(tài)置為prepare，等到commit提交事務(wù)后，會將此次事務(wù)中在redo log添加的記錄的狀態(tài)都置為commit狀態(tài)，之后將修改落盤時，會將redo log中狀態(tài)為commit的記錄的修改都寫入磁盤。

過程如下圖：

redo log記錄方式：

redolog的大小是固定的，在mysql中可以通過修改配置參數(shù)innodb_log_files_in_group和innodb_log_file_size配置日志文件數(shù)量和每個日志文件大小，redolog采用循環(huán)寫的方式記錄，當寫到結(jié)尾時，會回到開頭循環(huán)寫日志。

如下redolog記錄方式圖：

write pos表示日志當前記錄的位置，當ib_logfile_4寫滿后，會從ib_logfile_1從頭開始記錄；check point表示將日志記錄的修改寫進磁盤，完成數(shù)據(jù)落盤，數(shù)據(jù)落盤后checkpoint會將日志上的相關(guān)記錄擦除掉，即write pos->checkpoint之間的部分是redo log空著的部分，用于記錄新的記錄，checkpoint->write pos之間是redo log待落盤的數(shù)據(jù)修改記錄。當writepos追上checkpoint時，得先停下記錄，先推動checkpoint向前移動，空出位置記錄新的日志。
有了redo log，當數(shù)據(jù)庫發(fā)生宕機重啟后，可通過redo log將未落盤的數(shù)據(jù)恢復(fù)，即保證已經(jīng)提交的事務(wù)記錄不會丟失。有了redo log，為啥還需要binlog呢？

• 1、redo log的大小是固定的，日志上的記錄修改落盤后，日志會被覆蓋掉，無法用于數(shù)據(jù)回滾/數(shù)據(jù)恢復(fù)等操作。
• 2、redo log是innodb引擎層實現(xiàn)的，并不是所有引擎都有。

基于以上，binlog必不可少

• 1、binlog是server層實現(xiàn)的，意味著所有引擎都可以使用binlog日志
• 2、binlog通過追加的方式寫入的，可通過配置參數(shù)max_binlog_size設(shè)置每個binlog文件的大小，當文件大小大于給定值后，日志會發(fā)生滾動，之后的日志記錄到新的文件上。
• 3、binlog有兩種記錄模式，statement格式的話是記sql語句， row格式會記錄行的內(nèi)容，記兩條，更新前和更新后都有。

binlog和redo log必須保持一致，不允許出現(xiàn)binlog有記錄但redolog沒有的情況，反之亦然。之前說過在一個事務(wù)中，redolog有prepare和commit兩種狀態(tài)，所以，在redolog狀態(tài)為prepare時記錄binlog可保證兩日志的記錄一致，下圖列出各種情況來說明。

現(xiàn)在我們再來看看整個完整的流程圖：

相關(guān)參數(shù)設(shè)置建議：

• 1、innodb_flush_log_at_trx_commit：設(shè)置為1，表示每次事務(wù)的redolog都直接持久化到磁盤（注意是這里指的是redolog日志本身落盤），保證mysql重啟后數(shù)據(jù)不丟失。
• 2、sync_binlog： 設(shè)置為1，表示每次事務(wù)的binlog都直接持久化到磁盤（注意是這里指的是binlog日志本身落盤），保證mysql重啟后binlog記錄是完整的。

到此這篇關(guān)于mysql日志系統(tǒng)redo log和bin log介紹的文章就介紹到這了,更多相關(guān)mysql日志系統(tǒng) 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論