mysql的innodb中事務日誌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能力足夠支援業務，如充值消費，敏感業務;

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26855487/viewspace-776041/，如需轉載，請註明出處，否則將追究法律責任。