ib_logfile正如你所說，它是INNODB的REDO、UNDO日志，并不是備份用的日志。
MYSQL可以通過BINLOG來恢復(fù)，但這個ib_logfile沒什么恢復(fù)的作用，它主要是在事務(wù)中起一個前滾或后滾的作用。

?

mysql的innodb中事務(wù)日志ib_logfile
事務(wù)日志或稱redo日志，在mysql中默認以ib_logfile0,ib_logfile1名稱存在,可以手工修改參數(shù)，調(diào)節(jié)
開啟幾組日志來服務(wù)于當前mysql數(shù)據(jù)庫,mysql采用順序，循環(huán)寫方式，每開啟一個事務(wù)時，
會把一些相關(guān)信息記錄事務(wù)日志中(記錄對數(shù)據(jù)文件數(shù)據(jù)修改的物理位置或叫做偏移量);
作用:在系統(tǒng)崩潰重啟時，作事務(wù)重做；在系統(tǒng)正常時，每次checkpoint時間點，會將之前寫入事務(wù)
應(yīng)用到數(shù)據(jù)文件中。
引入一個問題：在m/s環(huán)境中,innodb寫完ib_logfile后,服務(wù)異常關(guān)閉，會不會主庫能用ib_logfile恢復(fù)數(shù)據(jù)，而
binlog沒寫導(dǎo)致從庫同步時少少這個事務(wù)？從而導(dǎo)致主從不一致;
redo日志寫入方式：
1.ib_logfile寫入當前事務(wù)更新數(shù)據(jù)，并標上事務(wù)準備trx_prepare
2.寫入bin-log
3.ib_logfile當前事務(wù)提交提交trx_commit
恢復(fù)方式:
如果ib_logfile已經(jīng)寫入事務(wù)準備,那么在恢復(fù)過程中，會依據(jù)bin-log中該事務(wù)是否存在恢復(fù)數(shù)據(jù)。
假設(shè):
1）結(jié)束后異常,因沒有寫入bin-log，從庫不會同步這個事務(wù)，主庫上，重啟時，在恢復(fù)日志中這個
事務(wù)沒有commit，即rollback這個事務(wù).
2）結(jié)束后異常，這會bin-log已經(jīng)寫入，從庫會同步這個事務(wù)。主庫依據(jù)恢復(fù)日志和bin-log，也正常恢復(fù)此事務(wù)
綜上描述:bin-log寫入完成，主從會正常完成事務(wù)；bin-log沒有寫入，主從庫rollback事務(wù);不會出現(xiàn)主從庫不一致問題.
相關(guān)參數(shù)（全局&靜態(tài)）:
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:事務(wù)日志緩存區(qū),可設(shè)置1M~8M,默認8M,延遲事務(wù)日志寫入磁盤,
把事務(wù)日志緩存區(qū)想象形如"漏斗"狀,會不停向磁盤記錄緩存的日志記錄,而何時寫入通過參數(shù)
innodb_flush_log_at_trx_commit控制,稍后解釋,啟用大的事務(wù)日志緩存,可以將完整運行大事
務(wù)日志，暫時存放在事務(wù)緩存區(qū)中,不必(事務(wù)提交前)寫入磁盤保存,同時也起到節(jié)約磁盤空間占用;
innodb_log_file_size:控制事務(wù)日志ib_logfile的大小,范圍5MB~4G；所有事務(wù)日志ib_logfile0+
ib_logfile1+..累加大小不能超過4G，事務(wù)日志大，checkpoint會少,節(jié)省磁盤IO，但是大的事務(wù)日
志意味著數(shù)據(jù)庫crash時，恢復(fù)起來較慢.
引入問題:修改該參數(shù)大小，導(dǎo)致ib_logfile文件的大小和之前存在的文件大小不匹配
解決方式：在干凈關(guān)閉數(shù)據(jù)庫情況下，刪除ib_logfile，而后重啟數(shù)據(jù)庫，會自行創(chuàng)建該文件;
innodb_log_files_in_group:DB中設(shè)置幾組事務(wù)日志，默認是2；
innodb_log_group_home_dir:事務(wù)日志存放目錄，不設(shè)置，ib_logfile0...存在在數(shù)據(jù)文件目錄下
innodb_flush_log_at_trx_commit：控制事務(wù)日志何時寫盤和刷盤，安全遞增：0,2,1
事務(wù)緩存區(qū):log_buffer;
0:每秒一次事務(wù)緩存區(qū)刷新到文件系統(tǒng)，同時文件系統(tǒng)到磁盤同步，但是事務(wù)提交時，不會觸發(fā)log_buffer到文件系統(tǒng)同步；
2:每次事務(wù)提交時,會把事務(wù)緩存區(qū)日志刷新到文件系統(tǒng)中去，且每秒文件系統(tǒng)到磁盤同步;
1:每次事務(wù)提交時刷新到磁盤，最安全;
適用環(huán)境:
0:磁盤IO能力有限,安全方便較差,無復(fù)制或復(fù)制延遲可以接受，如日志性業(yè)務(wù)，mysql損壞丟失1s事務(wù)數(shù)據(jù);
2:數(shù)據(jù)安全性有要求，可以丟失一點事務(wù)日志，復(fù)制延遲也可以接受，OS損壞時才可能丟失數(shù)據(jù);
1:數(shù)據(jù)安全性要求非常高，且磁盤IO能力足夠支持業(yè)務(wù)，如充值消費，敏感業(yè)務(wù);

mysql的innodb中事務(wù)日志ib_logfile