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

 

 

轉自：http://blog.itpub.net/26855487/viewspace-776041/

mysql的innodb中交易記錄ib_logfile