使用事務日志刷新延遲是否有危險-例如將innodb_flush_log_at_trx_commit設置為0？

Question

確實，啟用此選項的風險實際上比僅丟失最后N秒鍾的交易高嗎？

讓我解釋為什么我要問這個問題。 想象一下，數據庫服務器剛剛處理了事務T，並因此修改了一組索引頁。 這些索引頁中很少有已經刷新到磁盤的，而其他很少。 但是T還沒有將所有操作刷新到磁盤上的事務日志中。 現在我們關閉電源。

因此，當數據庫服務器重新啟動並嘗試恢復時，它在事務日志中看不到任何T操作。 但是它的某些索引實際上反映了這些操作，因為在電源故障之前已刷新了由T修改的某些索引頁。 即，結果是T的一部分被應用-並且可能以導致不一致的索引結構的方式（例如，表X的主索引不能反映T所做的任何更改，但是它的某些二級索引卻可以）。

因此，我想知道是否可以延遲事務日志刷新，而如果不這樣做，數據庫服務器實際上會采取什么措施來防止這種情況的發生（MySQL 5.5 w / InnoDB對我來說是最有趣的情況）。

Answer 1

在Quora上獲得了關於此問題的完整答案：

“還避免了檢查點（臟頁面刷新）fsync事務日志，以避免出現您提到的情況。后台線程計時器不是唯一的日志刷新源。請注意，這會引發瘋狂的警告，因為頁面中的LSN會是在您的事務日志LSN之前。

通常，在您確實不需要最后一個數據的情況下，在禁用事務日志刷新的情況下運行InnoDB是安全的（並且，如果您運行復制的安裝程序，則必須處理主數據庫上可能丟失的數據，這些數據可能存在於從數據庫上） ”。

Answer 2

幾年前Percona Live會議上的這份PDF撰寫得不錯（請參閱第55頁）。

簡短的答案：值0不會在COMMIT上刷新或同步，因此它根本不持久。 至少值為2時，您在COMMIT上刷新； 但是即使如此，您也只能每秒同步一次，因此通常也無法接受。

Answer 3

innodb_flush_log_at_trx_commit    
1  every commit log buffer flashed, synced,     no data loss
2  every commit log buffer flashed, not synced, data loss in OS crash or power loss
0  every second log buffer flashed, synced,     data loss on mysql crash, OS crash or power loss

我認為，如果您的數據不是很關鍵並且硬件有限，則可以使用innodb_flush_log_at_trx_commit=0 。 但是為了賺錢，必須使用銀行或安全解決方案innodb_flush_log_at_trx_commit=1來避免丟失任何數據。

Answer 4

簡短的回答-這很安全，但是如果OS或MySQL崩潰，您可能會丟失多達一秒鍾的已提交事務。

由您決定應用程序是否可接受（例如，財務軟件不會容忍數據丟失，但是如果丟失評論，博客將繼續存在）。