MySQL中的重作日誌，回滾日誌，以及二進制日誌的簡單總結

MySQL中有六種日誌文件，
分別是：重作日誌（redo log）、回滾日誌（undo log）、二進制日誌（binlog）、錯誤日誌（errorlog）、慢查詢日誌（slow query log）、通常查詢日誌（general log），中繼日誌（relay log）。
其中重作日誌和回滾日誌與事務操做息息相關，二進制日誌也與事務操做有必定的關係，這三種日誌，對理解MySQL中的事務操做有着重要的意義。
這裏簡單總結一下這三者具備必定相關性的日誌。

重作日誌（redo log）

做用：
　　確保事務的持久性。
　　防止在發生故障的時間點，尚有髒頁未寫入磁盤，在重啓mysql服務的時候，根據redo log進行重作，從而達到事務的持久性這一特性。
內容：
　　物理格式的日誌，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。
何時產生：
　　事務開始以後就產生redo log，redo log的落盤並非隨着事務的提交才寫入的，而是在事務的執行過程當中，便開始寫入redo log文件中。
何時釋放：
　　當對應事務的髒頁寫入到磁盤以後，redo log的使命也就完成了，重作日誌佔用的空間就能夠重用（被覆蓋）。
對應的物理文件：
　　默認狀況下，對應的物理文件位於數據庫的data目錄下的ib_logfile1&ib_logfile2
　　innodb_log_group_home_dir 指定日誌文件組所在的路徑，默認./ ，表示在數據庫的數據目錄下。
　　innodb_log_files_in_group 指定重作日誌文件組中文件的數量，默認2
　　關於文件的大小和數量，由一下兩個參數配置
　　innodb_log_file_size 重作日誌文件的大小。
　　innodb_mirrored_log_groups 指定了日誌鏡像文件組的數量，默認1
其餘：
　　很重要一點，redo log是何時寫盤的？前面說了是在事物開始以後逐步寫盤的。
　　之因此說重作日誌是在事務開始以後逐步寫入重作日誌文件，而不必定是事務提交才寫入重作日誌緩存，
　　緣由就是，重作日誌有一個緩存區Innodb_log_buffer，Innodb_log_buffer的默認大小爲8M(這裏設置的16M),Innodb存儲引擎先將重作日誌寫入innodb_log_buffer中。

　　

　　而後會經過如下三種方式將innodb日誌緩衝區的日誌刷新到磁盤
　　1，Master Thread 每秒一次執行刷新Innodb_log_buffer到重作日誌文件。
　　2，每一個事務提交時會將重作日誌刷新到重作日誌文件。
　　3，當重作日誌緩存可用空間 少於一半時，重作日誌緩存被刷新到重作日誌文件
　　由此能夠看出，重作日誌經過不止一種方式寫入到磁盤，尤爲是對於第一種方式，Innodb_log_buffer到重作日誌文件是Master Thread線程的定時任務。
　　所以重作日誌的寫盤，並不必定是隨着事務的提交才寫入重作日誌文件的，而是隨着事務的開始，逐步開始的。
　　另外引用《MySQL技術內幕 Innodb 存儲引擎》（page37）上的原話：
　　即便某個事務尚未提交，Innodb存儲引擎仍然每秒會將重作日誌緩存刷新到重作日誌文件。
　　這一點是必需要知道的，由於這能夠很好地解釋再大的事務的提交（commit）的時間也是很短暫的。

回滾日誌（undo log）

做用：
　　保存了事務發生以前的數據的一個版本，能夠用於回滾，同時能夠提供多版本併發控制下的讀（MVCC），也即非鎖定讀

內容：
　　邏輯格式的日誌，在執行undo的時候，僅僅是將數據從邏輯上恢復至事務以前的狀態，而不是從物理頁面上操做實現的，這一點是不一樣於redo log的。

何時產生：
　　事務開始以前，將當前是的版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性

何時釋放：
　　當事務提交以後，undo log並不能立馬被刪除，
　　而是放入待清理的鏈表，由purge線程判斷是否由其餘事務在使用undo段中表的上一個事務以前的版本信息，決定是否能夠清理undo log的日誌空間。

對應的物理文件：
　　MySQL5.6以前，undo表空間位於共享表空間的回滾段中，共享表空間的默認的名稱是ibdata，位於數據文件目錄中。
　　MySQL5.6以後，undo表空間能夠配置成獨立的文件，可是提早須要在配置文件中配置，完成數據庫初始化後生效且不可改變undo log文件的個數
　　若是初始化數據庫以前沒有進行相關配置，那麼就沒法配置成獨立的表空間了。
　　關於MySQL5.7以後的獨立undo 表空間配置參數以下
　　innodb_undo_directory = /data/undospace/ --undo獨立表空間的存放目錄
　　innodb_undo_logs = 128 --回滾段爲128KB
　　innodb_undo_tablespaces = 4 --指定有4個undo log文件

　　若是undo使用的共享表空間，這個共享表空間中又不只僅是存儲了undo的信息，共享表空間的默認爲與MySQL的數據目錄下面，其屬性由參數innodb_data_file_path配置。
　　

其餘：
　　undo是在事務開始以前保存的被修改數據的一個版本，產生undo日誌的時候，一樣會伴隨相似於保護事務持久化機制的redolog的產生。
　　默認狀況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當數據庫中發生一些大的事務性操做的時候，要生成大量的undo信息，所有保存在共享表空間中的。
　　所以共享表空間可能會變的很大，默認狀況下，也就是undo 日誌使用共享表空間的時候，被「撐大」的共享表空間是不會也不能自動收縮的。
　　所以，mysql5.7以後的「獨立undo 表空間」的配置就顯得頗有必要了。

二進制日誌（binlog）：

做用：
　　1，用於複製，在主從複製中，從庫利用主庫上的binlog進行重播，實現主從同步。
　　2，用於數據庫的基於時間點的還原。
內容：
　　邏輯格式的日誌，能夠簡單認爲就是執行過的事務中的sql語句。
　　但又不徹底是sql語句這麼簡單，而是包括了執行的sql語句（增刪改）反向的信息，
　　也就意味着delete對應着delete自己和其反向的insert；update對應着update執行先後的版本的信息；insert對應着delete和insert自己的信息。
　　在使用mysqlbinlog解析binlog以後一些都會真相大白。
　　所以能夠基於binlog作到相似於oracle的閃回功能，其實都是依賴於binlog中的日誌記錄。

何時產生：
　　事務提交的時候，一次性將事務中的sql語句（一個事物可能對應多個sql語句）按照必定的格式記錄到binlog中。
　　這裏與redo log很明顯的差別就是redo log並不必定是在事務提交的時候刷新到磁盤，redo log是在事務開始以後就開始逐步寫入磁盤。
　　所以對於事務的提交，即使是較大的事務，提交（commit）都是很快的，可是在開啓了bin_log的狀況下，對於較大事務的提交，可能會變得比較慢一些。
　　這是由於binlog是在事務提交的時候一次性寫入的形成的，這些能夠經過測試驗證。

何時釋放：
　　binlog的默認是保持時間由參數expire_logs_days配置，也就是說對於非活動的日誌文件，在生成時間超過expire_logs_days配置的天數以後，會被自動刪除。
　　

對應的物理文件：
　　配置文件的路徑爲log_bin_basename，binlog日誌文件按照指定大小，當日志文件達到指定的最大的大小以後，進行滾動更新，生成新的日誌文件。
　　對於每一個binlog日誌文件，經過一個統一的index文件來組織。

　

其餘：
　　二進制日誌的做用之一是還原數據庫的，這與redo log很相似，不少人混淆過，可是二者有本質的不一樣
　　1，做用不一樣：redo log是保證事務的持久性的，是事務層面的，binlog做爲還原的功能，是數據庫層面的（固然也能夠精確到事務層面的），雖然都有還原的意思，可是其保護數據的層次是不同的。
　　2，內容不一樣：redo log是物理日誌，是數據頁面的修改以後的物理記錄，binlog是邏輯日誌，能夠簡單認爲記錄的就是sql語句
　　3，另外，二者日誌產生的時間，能夠釋放的時間，在可釋放的狀況下清理機制，都是徹底不一樣的。
　　4，恢復數據時候的效率，基於物理日誌的redo log恢復數據的效率要高於語句邏輯日誌的binlog

　　關於事務提交時，redo log和binlog的寫入順序，爲了保證主從複製時候的主從一致（固然也包括使用binlog進行基於時間點還原的狀況），是要嚴格一致的，
　　MySQL經過兩階段提交過程來完成事務的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個日誌都提交成功（刷入磁盤），事務纔算真正的完成。
　　參考：http://www.cnblogs.com/hustcat/p/3577584.html

總結：

　　MySQL中，對於以上三種日誌，每一種細化起來均可以夠寫一個章節的，這裏粗略地總結了一下三種日誌的一些特色和做用，以幫助理解MySQL中的事物以及事物背後的原理。

參考：《MySQL技術內幕 Innodb 存儲引擎》

做者：MSSQL123
連接：http://www.cnblogs.com/wy123/p/8365234.html

更多資料詳情可關注二維碼獲取

更多精彩內容也可查看 https://xdclass.net/#/index