MariaDB——(二) MariaDB 10.0.15 日誌文件—undo 日誌

      日誌的記錄和維護是數據庫中至關重要的內容，寫這篇文章和後面幾篇文章做爲學習官網文檔的筆記。MariaDB數據庫日誌可分爲二進制日誌、查詢日誌、錯誤日誌、myISAM表日誌、relay日誌和撤銷日誌（undo log）。

      MariaDB（mysql）的undo log 保存數據被InnoDB事務修改前的版本，用於數據恢復或者提供給「一致讀consistent read」級別的事務讀取，具體細節以下：

      1.在某行數據被修改前，首先複製數據到undo log中，表中的每行數據包含一個指針指向undo log中最近的版本，redo log中的每行數據則包含一個指向前一個版本的指針（若是有的話），這樣每行被修改的數據就造成了一個記錄變動的「歷史鏈history chain」,或者稱之爲變動集吧。

      2.MariaDB中的每個事物都運行在必定的隔離級別上，這個隔離級別isolation level 決定了怎樣建立記錄的「視圖view」，對於READ UNCOMMITTED一般使用記錄當前的版本（無論是否提交，即「髒讀dirty reads」）。其它的事務隔離級別的視圖則在redo log中查找最後一次提交的版本，READ COMMITTED針對每一個表使用不一樣的視圖，REPEATABLE READ可重複度和SERIALIZABLE則針對全部的表使用統一的視圖。

      3.存在一個全局的變動集（history chain），當有事務提交時，則將該記錄版本添加到這個變動集中，這個變動集中的記錄是按照事務提交的前後順序保存的。

      4.MariaDB的purge thread會刪掉現有視圖（view）再也不須要的redo log中的記錄。

      在MariaDB中運行長事務會有哪些問題呢，從redo log工做的方式來考慮，首先的問題就是會形成redo log體積膨脹，由於較長的事務須要保存更多的版本歷史，另外一個問題是，若是事務須要讀取很早以前的版本，就會形成性能影響。雖然只讀的事務不會向redo log寫記錄，可是這些事務會阻止purge thread線程清除redo log，也會形成redo log臃腫。還有一個問題是，使用長事務更容易發生死鎖，固然死鎖和redo log沒有關係。

和undo log相關的一些系統變量配置：

       1.MariaDB的undo log一般是物理磁盤上的系統表空間的一部分，在10.0之後的版本中，可使用 innodb_undo_directory 和 innodb_undo_tablespaces系統變量來將undo log保存到指定的設備位置。

       2.innodb_undo_logs系統變量用於肯定每一個事物可用的最多回滾段數（undo log中的關於insert或者update操做的部分就是回滾段）。

       3.innodb_avaliable_undo_logs狀態變量保存InnoDB undo log中總的可用回滾段數。

       4.innodb_flush_log_at_trx_commit決定了事物寫入（flush）到undo log的頻率，調整這個參數能夠在速度和穩定性方面取得平衡（想必事物太頻繁的flush undo log會形成性能低下）， Binlog group commit and innodb_flush_log_at_trx_commit中有更詳細的說明。