首先,我們先來看看一次查詢/更新語句流程圖
mysql查詢/更新流程圖.png
本文會將重點放在執行器<->存儲引擎之間的交互。
mysql不是每次數據更改都立刻寫到磁盤,而是會先將修改后的結果暫存在內存中,當一段時間后,再一次性將多個修改寫到磁盤上,減少磁盤io成本,同時提高操作速度。
-
mysql通過WAL(write-ahead logging)技術保證事務
在同一個事務中,每當數據庫進行修改數據操作時,將修改結果更新到內存后,會在redo log添加一行記錄記錄“需要在哪個數據頁上做什么修改”,并將該記錄狀態置為prepare,等到commit提交事務后,會將此次事務中在redo log添加的記錄的狀態都置為commit狀態,之后將修改落盤時,會將redo log中狀態為commit的記錄的修改都寫入磁盤。過程如下圖
更新流程.png -
redo log記錄方式
redolog的大小是固定的,在mysql中可以通過修改配置參數innodb_log_files_in_group和innodb_log_file_size配置日志文件數量和每個日志文件大小,redolog采用循環寫的方式記錄,當寫到結尾時,會回到開頭循環寫日志。如下圖
redolog記錄方式.png
write pos表示日志當前記錄的位置,當ib_logfile_4寫滿后,會從ib_logfile_1從頭開始記錄;check point表示將日志記錄的修改寫進磁盤,完成數據落盤,數據落盤后checkpoint會將日志上的相關記錄擦除掉,即write pos->checkpoint之間的部分是redo log空著的部分,用于記錄新的記錄,checkpoint->write pos之間是redo log待落盤的數據修改記錄。當writepos追上checkpoint時,得先停下記錄,先推動checkpoint向前移動,空出位置記錄新的日志。
有了redo log,當數據庫發生宕機重啟后,可通過redo log將未落盤的數據恢復,即保證已經提交的事務記錄不會丟失。
有了redo log,為啥還需要binlog呢?
1、redo log的大小是固定的,日志上的記錄修改落盤后,日志會被覆蓋掉,無法用于數據回滾/數據恢復等操作。
2、redo log是innodb引擎層實現的,并不是所有引擎都有。
- 基于以上,binlog必不可少
1、binlog是server層實現的,意味著所有引擎都可以使用binlog日志
2、binlog通過追加的方式寫入的,可通過配置參數max_binlog_size設置每個binlog文件的大小,當文件大小大于給定值后,日志會發生滾動,之后的日志記錄到新的文件上。
3、binlog有兩種記錄模式,statement格式的話是記sql語句, row格式會記錄行的內容,記兩條,更新前和更新后都有。
binlog和redo log必須保持一致,不允許出現binlog有記錄但redolog沒有的情況,反之亦然。之前說過在一個事務中,redolog有prepare和commit兩種狀態,所以,在redolog狀態為prepare時記錄binlog可保證兩日志的記錄一致,下圖列出各種情況來說明。
4.png
現在我們再來看看整個完整的流程圖
更新流程.png
相關參數設置建議:
1、innodb_flush_log_at_trx_commit:設置為1,表示每次事務的redolog都直接持久化到磁盤(注意是這里指的是redolog日志本身落盤),保證mysql重啟后數據不丟失。
2、sync_binlog: 設置為1,表示每次事務的binlog都直接持久化到磁盤(注意是這里指的是binlog日志本身落盤),保證mysql重啟后binlog記錄是完整的。