點擊上方“小羅技術筆記”,關注公衆號
第一時間送達實用乾貨
作者:六點半起牀
來源:http://suo.im/6vKqvm
日誌是 mysql
數據庫的重要組成部分,記錄着數據庫運行期間各種狀態信息。mysql
日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進制日誌幾大類。作爲開發,我們重點需要關注的是二進制日誌( binlog
)和事務日誌(包括 redolog
和 undo log
),本文接下來會詳細介紹這三種日誌。
binlog
binlog
用於記錄數據庫執行的寫入性操作(不包括查詢)信息,以二進制的形式保存在磁盤中。binlog
是 mysql
的邏輯日誌,並且由 Server
層進行記錄,使用任何存儲引擎的 mysql
數據庫都會記錄 binlog
日誌。
邏輯日誌:可以簡單理解爲記錄的就是sql語句。
物理日誌:因爲
mysql
數據最終是保存在數據頁中的,物理日誌記錄的就是數據頁變更。
binlog
是通過追加的方式進行寫入的,可以通過 max_binlog_size
參數設置每個 binlog
文件的大小,當文件大小達到給定值之後,會生成新的文件來保存日誌。
binlog使用場景
在實際應用中, binlog
的主要使用場景有兩個,分別是主從複製和數據恢復。
1、 主從複製:在 Master
端開啓 binlog
,然後將 binlog
發送到各個 Slave
端, Slave
端重放 binlog
從而達到主從數據一致。2、 數據恢復:通過使用 mysqlbinlog
工具來恢復數據。
binlog刷盤時機
對於 InnoDB
存儲引擎而言,只有在事務提交時纔會記錄 biglog
,此時記錄還在內存中,那麼 biglog
是什麼時候刷到磁盤中的呢?mysql
通過 sync_binlog
參數控制 biglog
的刷盤時機,取值範圍是 0-N
:
0:不去強制要求,由系統自行判斷何時寫入磁盤;
1:每次
commit
的時候都要將binlog
寫入磁盤;N:每N個事務,纔會將
binlog
寫入磁盤。
從上面可以看出, sync_binlog
最安全的是設置是 1
,這也是 MySQL5.7.7
之後版本的默認值。但是設置一個大一些的值可以提升數據庫性能,因此實際情況下也可以將值適當調大,犧牲一定的一致性來獲取更好的性能。
binlog日誌格式
binlog
日誌有三種格式,分別爲 STATMENT
、 ROW
和 MIXED
。
在
MySQL5.7.7
之前,默認的格式是STATEMENT
,MySQL5.7.7
之後,默認值是ROW
。日誌格式通過binlog-format
指定。
STATMENT
基於SQL
語句的複製(statement-based replication,SBR
),每一條會修改數據的sql語句會記錄到binlog
中。優點:不需要記錄每一行的變化,減少了binlog
日誌量,節約了IO
, 從而提高了性能;缺點:在某些情況下會導致主從數據不一致,比如執行sysdate()
、slepp()
等。ROW
基於行的複製(row-based replication,RBR
),不記錄每條sql語句的上下文信息,僅需記錄哪條數據被修改了。優點:不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正確複製的問題;缺點:會產生大量的日誌,尤其是alter table
的時候會讓日誌暴漲MIXED
基於STATMENT
和ROW
兩種模式的混合複製(mixed-based replication,MBR
),一般的複製使用STATEMENT
模式保存binlog
,對於STATEMENT
模式無法複製的操作使用ROW
模式保存binlog
redo log
爲什麼需要redo log
我們都知道,事務的四大特性裏面有一個是持久性,具體來說就是只要事務提交成功,那麼對數據庫做的修改就被永久保存下來了,不可能因爲任何原因再回到原來的狀態。那麼 mysql
是如何保證一致性的呢?最簡單的做法是在每次事務提交的時候,將該事務涉及修改的數據頁全部刷新到磁盤中。但是這麼做會有嚴重的性能問題,主要體現在兩個方面:
1、 因爲 Innodb
是以 頁
爲單位進行磁盤交互的,而一個事務很可能只修改一個數據頁裏面的幾個字節,這個時候將完整的數據頁刷到磁盤的話,太浪費資源了!2、 一個事務可能涉及修改多個數據頁,並且這些數據頁在物理上並不連續,使用隨機IO寫入性能太差!
因此 mysql
設計了 redolog
,具體來說就是隻記錄事務對數據頁做了哪些修改,這樣就能完美地解決性能問題了(相對而言文件更小並且是順序IO)。
redo log基本概念
redolog
包括兩部分:一個是內存中的日誌緩衝( redolog buffer
),另一個是磁盤上的日誌文件( redolog file
)。mysql
每執行一條 DML
語句,先將記錄寫入 redolog buffer
,後續某個時間點再一次性將多個操作記錄寫到 redolog file
。這種先寫日誌,再寫磁盤的技術就是 MySQL
裏經常說到的 WAL(Write-AheadLogging)
技術。
在計算機操作系統中,用戶空間( user space
)下的緩衝區數據一般情況下是無法直接寫入磁盤的,中間必須經過操作系統內核空間( kernel space
)緩衝區( OSBuffer
)。因此, redolog buffer
寫入 redolog file
實際上是先寫入 OSBuffer
,然後再通過系統調用 fsync()
將其刷到 redolog file
中,過程如下:
mysql
支持三種將 redolog buffer
寫入 redolog file
的時機,可以通過 innodb_flush_log_at_trx_commit
參數配置,各參數值含義如下:
參數值 | 含義 |
---|---|
0(延遲寫) | 事務提交時不會將 redolog buffer 中日誌寫入到 os buffer ,而是每秒寫入 os buffer 並調用 fsync() 寫入到 redolog file 中。也就是說設置爲0時是(大約)每秒刷新寫入到磁盤中的,當系統崩潰,會丟失1秒鐘的數據。 |
1(實時寫,實時刷) | 事務每次提交都會將 redolog buffer 中的日誌寫入 os buffer 並調用 fsync() 刷到 redolog file 中。這種方式即使系統崩潰也不會丟失任何數據,但是因爲每次提交都寫入磁盤,IO的性能較差。 |
2(實時寫,延遲刷) | 每次提交都僅寫入到 os buffer ,然後是每秒調用 fsync() 將 os buffer 中的日誌寫入到 redolog file 。 |
redo log記錄形式
前面說過, redolog
實際上記錄數據頁的變更,而這種變更記錄是沒必要全部保存,因此 redolog
實現上採用了大小固定,循環寫入的方式,當寫到結尾時,會回到開頭循環寫日誌。如下圖:
同時我們很容易得知,在innodb中,既有 redolog
需要刷盤,還有 數據頁
也需要刷盤, redolog
存在的意義主要就是降低對 數據頁
刷盤的要求。在上圖中, write pos
表示 redolog
當前記錄的 LSN
(邏輯序列號)位置, check point
表示數據頁更改記錄刷盤後對應 redolog
所處的 LSN
(邏輯序列號)位置。write pos
到 check point
之間的部分是 redolog
空着的部分,用於記錄新的記錄;check point
到 write pos
之間是 redolog
待落盤的數據頁更改記錄。當 write pos
追上 check point
時,會先推動 check point
向前移動,空出位置再記錄新的日誌。
啓動 innodb
的時候,不管上次是正常關閉還是異常關閉,總是會進行恢復操作。因爲 redolog
記錄的是數據頁的物理變化,因此恢復的時候速度比邏輯日誌(如 binlog
)要快很多。重啓 innodb
時,首先會檢查磁盤中數據頁的 LSN
,如果數據頁的 LSN
小於日誌中的 LSN
,則會從 checkpoint
開始恢復。還有一種情況,在宕機前正處於 checkpoint
的刷盤過程,且數據頁的刷盤進度超過了日誌頁的刷盤進度,此時會出現數據頁中記錄的 LSN
大於日誌中的 LSN
,這時超出日誌進度的部分將不會重做,因爲這本身就表示已經做過的事情,無需再重做。
redo log與binlog區別
redo log | binlog | |
---|---|---|
文件大小 | redolog 的大小是固定的。 |
binlog 可通過配置參數 max_binlog_size 設置每個 binlog 文件的大小。 |
實現方式 | redolog 是 InnoDB 引擎層實現的,並不是所有引擎都有。 |
binlog 是 Server 層實現的,所有引擎都可以使用 binlog 日誌 |
記錄方式 | redo log 採用循環寫的方式記錄,當寫到結尾時,會回到開頭循環寫日誌。 | binlog 通過追加的方式記錄,當文件大小大於給定值後,後續的日誌會記錄到新的文件上 |
適用場景 | redolog 適用於崩潰恢復(crash-safe) |
binlog 適用於主從複製和數據恢復 |
由 binlog
和 redolog
的區別可知:binlog
日誌只用于歸檔,只依靠 binlog
是沒有 crash-safe
能力的。但只有 redolog
也不行,因爲 redolog
是 InnoDB
特有的,且日誌上的記錄落盤後會被覆蓋掉。因此需要 binlog
和 redolog
二者同時記錄,才能保證當數據庫發生宕機重啓時,數據不會丟失。
undo log
數據庫事務四大特性中有一個是原子性,具體來說就是 原子性是指對數據庫的一系列操作,要麼全部成功,要麼全部失敗,不可能出現部分成功的情況。實際上,原子性底層就是通過 undo log
實現的。undo log
主要記錄了數據的邏輯變化,比如一條 INSERT
語句,對應一條 DELETE
的 undo log
,對於每個 UPDATE
語句,對應一條相反的 UPDATE
的 undo log
,這樣在發生錯誤時,就能回滾到事務之前的數據狀態。同時, undo log
也是 MVCC
(多版本併發控制)實現的關鍵,這部分內容在[面試中的老大難-mysql事務和鎖,一次性講清楚!][-mysql]中有介紹,不再贅述。
長按二維碼關注
點個在看再走唄!
本文分享自微信公衆號 - 小羅技術筆記(javaCodeNote)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。