重作日誌相關

Ⅰ、事務的實現

這裏咱們先拋出答案,經過答案再展開分析mysql

特性 實現
A(原子性) redo
C(一致性) undo
I(隔離性) lock
D(持久性) redo/undo

本節針對redo展開分析sql

Ⅱ、redo詳解

2.1 redo log buffer

  • redo就是咱們常說的重作日誌,用來實現持久性
  • mysql目錄下兩個ib_logfile文件,就是重作日誌文件,在ssd場景下至少設置爲4G
  • redo log裏面記錄的是每一個page修改操做的物理邏輯日誌(不是徹底的二進制的差別值,好比一個sql修改了一千萬行,一千萬個page被修改了,那記錄的是1000w page的變化,而不是sql語句)

redo由redo log buffer和redo log file組成,重作日誌先寫入一塊內存,再按期刷新到磁盤緩存

先看下redo log bufferoracle

它由不少個log block組成,每一個log block 512個字節,不須要doublewrite
性能

innodb_log_buffer_size    8M便可,不須要太大,一秒鐘寫滿8M不太可能

redo log刷盤的條件spa

①master thread    每秒從內存刷到磁盤
  5.6版本後,增長innodb_flush_log_at_timeout參數,能夠設置刷新間隔,默認爲1,調大一點可減小io,提高性能,但不建議

②redo log buffer  使用大於1/2也會刷

③事務提交時進行刷新,即便上面兩個條件不知足(事務持久性的要求)
  innodb_flush_log_at_trx_commit={0|1|2},默認爲1,事務提交時將redo log buffer寫到磁盤(即便上面兩個條件不知足,這樣crash了就還能夠經過redo恢復),只有是1的時候innodb才能真正達到持久性的標準
  事務對page作了修改,提交的時候並不須要保證贓頁刷到磁盤,只須要保證將對應修改的日誌刷過去就能夠了
  0表示交給master thread每秒刷新,事務提交不將redo log buffer刷到磁盤,最多會丟失1s的事務
  2表示事務提交時僅將redo log buffer寫到操做系統緩存,因此mysql重啓,只要操做系統沒重啓,那數據仍是在的額

2.2 redo log file

先弄個圖看看redo buffer刷盤吧操作系統

每一個ib_logfile都分爲不少個512bits的塊,最前頭2k是留出來寫checkpoint的,經過對比兩個cp可知哪一個是最新的,cp1和cp2輪詢寫確保cp不會壞掉,一個壞了也沒事,即便用小的cp頂多就是恢復的時候多一點時間,沒有oracle的歸檔

優勢: 這樣作的好處是不須要歸檔,少了IO操做
缺點: 若是redo_log_file過小則可能須要等待,由於當要覆蓋log_file中的log_block時,若是該log_block中的髒頁尚未進行刷新的話,則須要等待這個髒頁進行刷新
因此須要把redo log file設置的儘量的大

redo日誌分類3d

物理日誌:記錄整個page的變化(diff)日誌

邏輯日誌:Like SQL語句code

物理邏輯日誌:根據page進行記錄,內容邏輯

redo log file與redo log buffer內容一致

+---------------+----------+---------+---------------+
| redo_log_type | space no | page no | redo log body |
+---------------+----------+---------+---------------+
#  redo log 類型  表空間號     頁號    redo log 內容
MLOG_REC_INSERT
+------+--------+------+---------+------------+-------+---------+-----------+----------+
| type | space  | page | cur_rec | len &      | info  | origin  | mis_match | rec body |
|      |   no   |  no  | _offset | extra_info | _bits | _offset | _index    |          |
+------+--------+------+---------+------------+-------+---------+-----------+----------+
MLOG_REC_DELETE
+------+----------+---------+--------+
| type | space no | page no | offset |
+------+----------+---------+--------+

rec body根據page的變化來記錄,而不是根據操做SQL來記錄,因此偏物理日誌
由於還記錄了redo log body,一個具體操做,因此又叫邏輯

每種不一樣類型的redo log的內在格式可能長得不同

相關參數

innodb_log_file_size 單個redo文件大小(推薦8G,官方推薦等於bp)
  以前不建議調大由於有bug,若是調大,恢復速度會很慢O(N^2)
  5.5版本的redo文件總大小(num * size)最大隻能4G
  5.6以後限制未512G,調大後惟一的問題就是恢復的內容變多了
  5.6以後,正常關閉MySQL,而後調整該值,會自動調整文件大小
innodb_log_files_in_group
innodb_log_group_home_dir 和數據文件分開,選擇更快的磁盤
相關文章
相關標籤/搜索