MySQL事務日誌

Question

我正在爲我們需要在我們的DBMS（MySQL）中使用「事務日誌」的項目工作。我們已經轉向使用InnoDB，以便將事務用於其他需求。我想了解什麼是事務日記。我一直在尋找一整天，包括閱讀MySQL文檔。也許我只是沒有搜索正確的關鍵字，我不確定。或者，「交易日記」可能是不恰當的術語。

據我所知，數據庫事務日誌類似於日誌文件系統，因爲日誌文件在提交到文件系統之前會對其進行更改。從我讀到的內容來看，這聽起來像InnoDB引擎在將某些日記交給磁盤之前將其存儲在某種日記中。這聽起來準確嗎？如果是這樣，交易日誌在哪裏？它是ib_logfile0和ib_logfile1嗎？

Answer 1

你絕對是在這裏正確的軌道上。

每當InnoDB執行一個必須提交的事務時，它將作爲一個兩階段提交完成。事務首先被寫入這些日誌中。然後，他們從那裏承諾。

這有助於MySQL事故或服務器崩潰事件。

當你重啓MySQL，在ib_logfile0所有未提交的條目和ib_logfile1重播作爲的InnoDB的崩潰恢復帶來的InnoDB的和諧狀態的一部分（這是一貫和ACID Compliance耐用的零件）

如果刪除ib_logfile0和ib_logfile1並啓動mysql，這些文件包含的任何未提交的事務都將丟失。在崩潰恢復週期中，如果日誌文件丟失，則基於innodb_log_file_size設置重新生成日誌文件。請參閱MySQL Documentation for a detailed explanation of InnoDB。

@karatedog InnoDB的MVCC部分發生在系統表空間中，更好地稱爲ibdata1。無論在事務開始之前顯示的數據是否被記錄，以允許其他訪問所需行的人在施加任何更新之前都有數據的視圖。這是允許所謂的可重複閱讀。這屬於ACID合規性的I，我的意思是隔離。我在DBA StackExchange中針對事務隔離是好的，壞的或醜陋的各種場景寫了關於這方面的文章。

• read before write transaction
• Will these two queries result in a deadlock if executed in sequence?
• Is raid 5 suitable for mysql installation?

作爲對MyISAM，crash recovery is not automatic. It crashes rather easily。這就是SQL命令REPAIR TABLE存在的原因。這也是爲什麼MySQL實用程序myisamchk具有-r選項可以爲不在線的MyISAM表執行REPAIR TABLE。

MariaDB and Aria已經嘗試使用安全防撞存儲引擎來替代MyISAM。