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能力足夠支持業務，如充值消費，敏感業務;

mysql的innodb中事務日志ib_logfile