mysql的innodb中事務日誌ib_logfile

ib_logfile正如你所說，它是INNODB的REDO、UNDO日誌，並非備份用的日誌。
MYSQL能夠經過BINLOG來恢復，但這個ib_logfile沒什麼恢復的做用，它主要是在事務中起一個前滾或後滾的做用。

 

mysql的innodb中事務日誌ib_logfile
事務日誌或稱redo日誌，在mysql中默認以ib_logfile0,ib_logfile1名稱存在,能夠手工修改參數，調節
開啓幾組日誌來服務於當前mysql數據庫,mysql採用順序，循環寫方式，每開啓一個事務時，
會把一些相關信息記錄事務日誌中(記錄對數據文件數據修改的物理位置或叫作偏移量);
做用:在系統崩潰重啓時，做事務重作；在系統正常時，每次checkpoint時間點，會將以前寫入事務
應用到數據文件中。
引入一個問題：在m/s環境中,innodb寫完ib_logfile後,服務異常關閉，會不會主庫能用ib_logfile恢復數據，而
binlog沒寫致使從庫同步時少少這個事務？從而致使主從不一致;
redo日誌寫入方式：
1.ib_logfile寫入當前事務更新數據，並標上事務準備trx_prepare
2.寫入bin-log
3.ib_logfile當前事務提交提交trx_commit
恢復方式:
若是ib_logfile已經寫入事務準備,那麼在恢復過程當中，會依據bin-log中該事務是否存在恢復數據。
假設:
1）結束後異常,因沒有寫入bin-log，從庫不會同步這個事務，主庫上，重啓時，在恢復日誌中這個
事務沒有commit，即rollback這個事務.
2）結束後異常，這會bin-log已經寫入，從庫會同步這個事務。主庫依據恢復日誌和bin-log，也正常恢復此事務
綜上描述:bin-log寫入完成，主從會正常完成事務；bin-log沒有寫入，主從庫rollback事務;不會出現主從庫不一致問題.
相關參數（全局&靜態）:
innodb_log_buffer_size
innodb_log_file_size
innodb_log_files_in_group
innodb_log_group_home_dir
innodb_flush_log_at_trx_commit
innodb_log_buffer_size:事務日誌緩存區,可設置1M~8M,默認8M,延遲事務日誌寫入磁盤,
把事務日誌緩存區想象形如"漏斗"狀,會不停向磁盤記錄緩存的日誌記錄,而什麼時候寫入經過參數
innodb_flush_log_at_trx_commit控制,稍後解釋,啓用大的事務日誌緩存,能夠將完整運行大事
務日誌，暫時存放在事務緩存區中,沒必要(事務提交前)寫入磁盤保存,同時也起到節約磁盤空間佔用;
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能力足夠支持業務，如充值消費，敏感業務;