|
概念:& n4 J& z, X1 O( W" ^1 ~+ R! P3 r+ U4 l
事務日誌或稱redo日誌,在mysql中默認以ib_logfile0,ib_logfile1名稱存在,可以手工修改參數,調節開啟幾組日誌來服務於當前mysql數據庫,mysql采用順序,循環寫方式,每開啟一個事務時,會把一些相關信息記錄事務日誌中(記錄對數據文件數據修改的物理位置或叫做偏移量);2 z- X. K+ w; U- X* y. X: L2 S
這個系列文件個數由參數innodb_log_files_in_group控制,若設置為4,則命名為ib_logfile0~3。. D6 o6 }/ @6 i5 Q. T
這些文件的寫入是順序、循環寫的,logfile0寫完從logfile1繼續,logfile3寫完則logfile0繼續。: h6 _+ L0 \& O9 W/ A* G
3 I: P, M& Q9 V9 o- S, F) T) l作用:
$ P& S2 t* [6 e: `0 j% l! }在系統崩潰重啟時,作事務重做;在系統正常時,每次checkpoint時間點,會將之前寫入事務應用到數據文件中。- e4 J$ T; _* K" M5 v" I
4 v" s( |8 w0 L
Ib_logfile的checkpoint field
6 _" X! i' f7 @0 A l實際上不僅要記錄checkpoint做到哪兒(LOG_CHECKPOINT_LSN),還要記錄用到了哪個位置(LOG_CHECKPOINT_OFFSET)等其他信息。所以在ib_logfile0的頭部預留了空間,用於記錄這些信息。
9 \& L8 B; l( c% R8 \6 z6 V% L$ P因此即使使用後面的logfile,每次checkpoint完成後,ib_logfile0都是要更新的。同時你會發現所謂的順序寫盤,也並不是絕對的2 j6 @8 \8 ~$ ]+ x" N4 E4 I( o
相關的一些數字8 a2 z; }4 w' V
a) InnoDB留了兩個checkpoint filed,按照註釋的解釋,目的是為了能夠“write alternately”5 S2 u, g; x* R$ i0 E
b) 每個checkpint field需要的大小空間為304字節。(相關定義在log0log.h)2 s H9 n) V N' ~
c) 第一個checkpoint的起始位置在ib_logfile0的第512字節(OS_FILE_LOG_BLOCK_SIZE)處;* [$ l9 S! z2 D! n* [
d) 第二個在1536 (3 * OS_FILE_LOG_BLOCK_SIZE)字節處。+ ~4 `! N" [( t: m4 b6 F) i
5 N2 V. j) H$ u& f3 P! ]
" Y+ x! S+ R1 _' K7 U2 Z8 g4 A特點:
2 Q7 x8 Y, o; c' A2 f" k. mredo log只是記錄所有innodb表數據的變化。
2 ]( M) M$ r1 L& f, Gredo log只是記錄正在執行中的dml以及ddl語句。: P# R5 U+ z+ k/ A4 I
redo log可以作為異常down機或者介質故障後的數據恢復使用 引入一個問題:在m/s環境中,innodb寫完ib_logfile後,服務異常關閉,會不會主庫能用ib_logfile恢復數據,而binlog沒寫導致從庫同步時少了這個事務?從而導致主從不一致;redo日誌寫入方式:1.ib_logfile寫入當前事務更新數據,並標上事務準備trx_prepare2.寫入bin-log3.ib_logfile當前事務提交提交trx_commit恢復方式:如果ib_logfile已經寫入事務準備,那麽在恢復過程中,會依據bin-log中該事務是否存在恢復數據。假設:1)結束後異常,因沒有寫入bin-log,從庫不會同步這個事務,主庫上,重啟時,在恢復日誌中這個事務沒有commit,即rollback這個事務.2)結束後異常,這會bin-log已經寫入,從庫會同步這個事務。主庫依據恢復日誌和bin-log,也正常恢復此事務綜上描述:bin-log寫入完成,主從會正常完成事務;bin-log沒有寫入,主從庫rollback事務;不會出現主從庫不一致問題.8 T; M6 d9 h8 v2 E% I) P
相關參數(全局&靜態):innodb_log_buffer_sizeinnodb_log_file_sizeinnodb_log_files_in_groupinnodb_log_group_home_dirinnodb_flush_log_at_trx_commitinnodb_log_buffer_size:事務日誌緩存區,可設置1M~8M,默認8M,延遲事務日誌寫入磁盤,把事務日誌緩存區想象形如"漏鬥"狀,會不停向磁盤記錄緩存的日誌記錄,而何時寫入通過參數innodb_flush_log_at_trx_commit控制,稍後解釋,啟用大的事務日誌緩存,可以將完整運行大事務日誌,' y8 { c! j/ r2 C! o4 n" l8 |! }
暫時存放在事務緩存區中,不必(事務提交前)寫入磁盤保存,同時也起到節約磁盤空間占用;innodb_log_file_size:控制事務日誌ib_logfile的大小,範圍5MB~4G;所有事務日誌ib_logfile0+ib_logfile1+..累加大小不能超過4G,事務日誌大,checkpoint會少,節省磁盤IO,但是大的事務日誌意味著數據庫crash時,恢復起來較慢.引入問題:修改該參數大小,導致ib_logfile文件的大小和之前存在的文件大小不匹配解決方式:在幹凈關閉數據庫情況下,刪除ib_logfile,而後重啟數據庫,會自行創建該文件;innodb_log_files_in_group:DB中設置幾組事務日誌,默認是2;innodb_log_group_home_dir:事務日誌存放目錄,不設置,ib_logfile0...存在在數據文件目錄下innodb_flush_log_at_trx_commit:控制事務日誌何時寫盤和刷盤,安全遞增:0,2,1事務緩存區:log_buffer;0:每秒一次事務緩存區刷新到文件系統,同時文件系統到磁盤同步,但是事務提交時,不會觸發log_buffer到文件系統同步;2:每次事務提交時,會把事務緩存區日誌刷新到文件系統中去,且每秒文件系統到磁盤同步;1:每次事務提交時刷新到磁盤,最安全;適用環境:0:磁盤IO能力有限,安全方便較差,無復制或復制延遲可以接受,如日誌性業務,mysql損壞丟失1s事務數據;2:數據安全性有要求,可以丟失一點事務日誌,復制延遲也可以接受,OS損壞時才可能丟失數據;1:數據安全性要求非常高,且磁盤IO能力足夠支持業務,如充值消費,敏感業務;
6 Y* n4 v4 [8 I( B# }9 B, ^+ w0 N8 m3 _9 c J1 O! ]1 O; g
引入ib_logfile的寫入策略 1、基本概念
. o: u) M; o7 ?# ^; ha)、ib_logfile文件個數由innodb_log_files_in_group配置決定,若為2,則在datadir目錄下有兩個文件,命令從0開始,分別為ib_logfile0和ib_logfile.
- [4 f8 _& V3 L( f' A1 u3 z( Ib)、文件為順序寫入,當達到最後一個文件末尾時,會從第一個文件開始順序復用。
. t" H3 B% l9 ~# Pc)、lsn: Log Sequence Number,是一個遞增的整數。 Ib_logfile中的每次寫入操作都包含至少1個log,每個log都帶有一個lsn。在內存page修復過程中,只有大於page_lsn的log才會被使用。
! z. W$ [( R3 R# G$ k& j. Zd)、lsn的保存在全局變量log_sys中。遞增數值等於每個log的實際內容長度。即如果新增的一個log長度是len,則log_sys->lsn += len.; t0 q3 Q; V3 s5 S% F* V' i, K
e)、ib_logfile每次寫入以512(OS_FILE_LOG_BLOCK_SIZE)字節為單位。實際寫入函數 log_group_write_buf (log/log0log.c)
* k) t5 s W$ Kf)、每次寫盤後是否flush,由參數innodb_flush_log_at_trx_commit控制。- |# z$ d' V# T2 m1 _1 P' e
" r$ e' |5 b: A6 g9 ]
2 n: j2 o6 @; t q* n
2、log_sys介紹5 |" T- ]& i8 W( O( H, K: N
log_sys是一個全局內存結構。以下說明幾個成員的意義。' K* ]3 S n1 ^3 e! `6 [
| | | lsn | 表示已經分配的最後一個lsn的值。 | | written_to_all_lsn | n表示實際已經寫盤的lsn。需要這個值是因為並非每次生成log後就寫盤。 | | flushed_to_disk_lsn | 表示刷到磁盤的lsn。需要這個值是因為並非每次寫盤後就flush。 | | buf | 待寫入的內容保存在buf中 | | buf_size | buf的大小。由配置中innodb_log_buffer_size決定,實際大小為innodb_log_buffer_size /16k * 16k。 | | buf_next_to_write | buf中下一個要寫入磁盤的位置 | | buf_free | buf中實際內容的最後位置。當buf_free> buf_next_to_write時,說明內存中還有數據未寫盤。 |
/ c& o+ T9 G/ A9 t" B- i7 V, _
- a S, |5 s8 V+ Q$ b
* _) J5 }5 K) B5 a3、相關更新- w( B7 Q( K8 k4 J( Y
用一個簡單的更新語句來說明log_sys以及ib_logfile的更新內容的過程。假設我們的更新只涉及到非索引的固定長度字段。
' G W+ S7 b: W. i3 \' K8 Ga) 在bufferpool中寫入undo log。 對於一個單一的語句,需要先創建一個undolog頭。8 W+ \/ N+ b; X2 W6 T3 k1 C5 A
b) 在bufferpool中寫入undo log的實際內容。
1 S$ i2 R. \% l& L9 O% |c) 在log_sys->buf中寫入buffer page的更新內容。此處保存了更新的完整信息。
3 { h: G' d6 }d) 在log_sys->buf中寫入啟動事務(trx_prepare)的日誌
# w7 o. K1 V4 {$ Ve) 將c、d更新的log內容寫入ib_logfile中。
# L6 s" a4 M. p& B( W2 q- P. Sf) 在log_sys->buf中寫入事務結束(trx_commit)的日誌! a8 G& d$ ]( R6 Y
g) 將f步驟的log內容寫入ib_logfile中。
6 `9 B# J' y9 v9 @' L1 o5 M4 T+ {, z# ^1 `6 T6 b0 ]$ u
4、說明
9 O3 P5 `+ d- ] y2 Y9 @a) 完成上述所有操作時,數據文件還沒有更新。+ }; |. `- h( J% R; w/ r' H2 [6 K
b) 每次寫入log_sys->buf時同時更新lsn和buf_free。 每次寫ib_logfile時同時更新written_to_all_lsn和buf_next_to_write;
& a% J. D m3 b) s. C5 Fc) 每次寫ib_logfile時以512字節為對齊,如需寫入600字節,則實際寫入1k。寫到最後一個文件末尾則從第一個文件重復使用。( p" R. e7 T7 n5 G6 A; X$ z3 J
d) 從上述流程看到,在a~d過程中若出現異常關閉,由於沒有寫入到磁盤中,因此整個事務放棄;若在e剛完成時出現異常關閉,雖然事務內容已經寫盤,但沒有提交。在重啟恢復的時候,發現這個事務還沒有提交,邏輯上整個事務放棄。 (重啟日誌中會有Found 1 prepared transaction(s) in InnoDB字樣)。在g完成後出現異常關閉,則能夠在重啟恢復中正常提交。
. F' I y* e, r9 D6 _, q
4 p E$ m3 d ~0 x$ k% E- D在e和f之間會寫mysql的bin-log,若bin-log寫完前異常關閉,事務無效,bin-log寫入成功後,則異常重啟後能夠根據bin-log恢復事務的修改。
, ?" @# \0 m: V' v& \: u4 `8 y6 b' n3 ?+ W- N: v0 |1 X6 f8 x
e) 若涉及到索引更新,在步驟c之後會增加索引更新的log。由於索引可能有merge過程,因此在merge過程中會另外增加寫入一個log。但事務完全提交仍在步驟g中。索引的更新由於已經寫盤,並不會因此丟失。
|