優質博文：IT-BLOG-CN
一、binlog
binlog記錄資料庫表結構和表資料變更，比如update/delete/insert/truncate/create，它不會記錄select。儲存著每條變更的SQL語句和XID事務Id等等。binlog日誌檔案如下：
[root@192.168.10.11]# mysqlbinlog mysql-binlog.0000012
..........
# at 523
# 168654 20:22:43 server id 1 end_log_pos 843 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=156521934/*!*/;
INSERT INTO student('name','age','sex') VALUES('ZZX',20,'1'); # 執行的SQL語句
/*!*/;
# at 669
#168654 20:22:45 server id 1 end_log_pos 876 Xid = 12 #執行的時間和事務ID
主要有兩個作用：複製和恢復資料
【1】MySQL架構為了高可用性都是一主多從，從伺服器需要與主伺服器保持資料一致，這就是透過binlog進行復制；
【2】資料庫的資料如果被誤刪，可以透過binlog資料進行恢復。
因為
binlog記錄了資料庫表的邏輯變更，所以可以用binlog進行主從複製和恢復資料。
二、redo log
MySQL執行SQL修改語句時，肯定是先把這條記錄查出來，然後再將這條進行進行修改。因為Mysql的基本儲存結構是頁，記錄都存在頁裡邊，所以MySQL是先把這條記錄所在的頁找到，然後把該頁載入到記憶體中，將對應記錄進行修改。現在就可能存在一個問題：如果在記憶體中把資料改了，還沒來得及落磁碟，而此時的資料庫掛了，導致這次修改丟失了怎麼辦？
如果每個請求都需要將資料立馬同步到磁碟，那速度會很慢，MySQL可能也頂不住。所以MySQL引入了redo log，記憶體寫完了，然後會寫一份redo log，這份redo log記載著這次在某個頁上做了什麼修改。
寫redo log的時候，也會有buffer，是先寫buffer，再真正落到磁碟中的。至於從buffer什麼時候落磁碟，會有配置供我們配置。
寫redo log也是需要寫磁碟的，但它的好處就是順序IO（我們都知道順序IO比隨機IO快非常多）。
所以，redo log的存在為了：當我們修改的時候，寫完記憶體了，但資料還沒真正寫到磁碟的時候。此時我們的資料庫掛了，我們可以根據redo log來對資料進行恢復。因為redo log是順序IO，所以寫入的速度很快，並且redo log記載的是物理變化（x頁做了y修改），檔案的體積很小，恢復速度很快。
三、binlog與redolog的區別
兩個日誌較為相似，這裡總結下兩者的主要區別：
【1】儲存內容不同： binlog記載的是update/delete/insert這樣的SQL語句，而redo log記載的是物理修改的內容（x頁修改了y）。redo log記錄的是資料的物理變化，binlog記錄的是資料的邏輯變化。
【2】功能： redo log的作用是為持久化而生的。寫完記憶體，如果資料庫掛了，那我們可以透過redo log來恢復記憶體還沒來得及刷到磁碟的資料，將redo log載入到記憶體裡邊，那記憶體就能恢復到掛掉之前的資料了。
binlog的作用是複製和恢復而生的。主從伺服器需要保持資料的一致性，透過binlog來同步資料。如果整個資料庫的資料都被刪除了，binlog儲存著所有的資料變更情況，那麼可以透過binlog來對資料進行恢復。
如果整個資料庫的資料都被刪除了，那我可以用redo log的記錄來恢復嗎？
不能，因為功能的不同，redo log 儲存的是物理資料的變更，如果我們記憶體的資料已經刷到了磁碟了，那redo log的資料就無效了。所以redo log不會儲存著歷史所有資料的變更，檔案的內容會被覆蓋的。
【3】寫入細節不同： redo log是MySQL的InnoDB引擎所產生的。binlog無論MySQL任何引擎都會有的。
InnoDB是有事務的，事務的四大特性之一：永續性就是靠redo log來實現的（如果寫入記憶體成功，但資料還沒真正刷到磁碟，如果此時的資料庫掛了，我們可以靠redo log來恢復記憶體的資料，這就實現了永續性）。
上面也提到，在修改的資料的時候，binlog會記載著變更的類容，redo log也會記載著變更的內容。（只不過一個儲存的是物理變化，一個儲存的是邏輯變化）。那他們的寫入順序是什麼樣的呢？
redo log事務開始的時候，就開始記錄每次的變更資訊，而binlog是在事務提交的時候才記錄。
於是新有的問題又出現了：我寫其中的某一個log，失敗了，那會怎麼辦？現在我們的前提是先寫redo log，再寫binlog，我們來看看：
■ 如果寫redo log失敗了，那我們就認為這次事務有問題，回滾，不再寫binlog。
■ 如果寫redo log成功了，寫binlog，寫binlog寫一半了，但失敗了怎麼辦？我們還是會對這次的事務回滾，將無效的binlog給刪除（因為binlog會影響從庫的資料，所以需要做刪除操作）
■ 如果寫redo log和binlog都成功了，那這次算是事務才會真正成功。
簡單來說：MySQL需要保證redo log和binlog的資料是一致的，如果不一致，那就亂套了。
■ 如果redo log寫失敗了，而binlog寫成功了。那假設記憶體的資料還沒來得及落磁碟，機器就掛掉了。那主從伺服器的資料就不一致了。（從伺服器透過binlog得到最新的資料，而主伺服器由於redo log沒有記載，沒法恢復資料）
■ 如果redo log寫成功了，而binlog寫失敗了。那從伺服器就拿不到最新的資料了。
MySQL透過兩階段提交來保證redo log和binlog的資料是一致的。
階段1：InnoDB redo log寫盤，InnoDB事務進入prepare狀態
階段2：binlog寫盤，InooDB事務進入commit狀態
每個事務binlog的末尾，會記錄一個XID event，標誌著事務是否提交成功，也就是說，恢復過程中，binlog最後一個XID event之後的內容都應該被purge。
如果binlog沒有正常關閉，mysql server可能crash過，我們需要呼叫MYSQL_BIN_LOG::recover:找到最後一個XID完成最後一次事務的兩階段提交InnoDB commit。因此，需要遍歷binlog檔案，找到最後一個合法event集合，並purge無效binlog
四、relay-log
從伺服器I/O執行緒將主伺服器的二進位制日誌讀取過來記錄到從伺服器本地檔案，然後從伺服器SQL執行緒會讀取relay-log日誌的內容並應用到從伺服器，從而使從伺服器和主伺服器的資料保持一致
show variables like '%relay%';
#結果
+---------------------------+----------------------------------+
| Variable_name | Value |
+---------------------------+----------------------------------+
| max_relay_log_size | 0 |
| relay_log | relay-mysql |
| relay_log_basename | /var/lib/mysql/relay-mysql |
| relay_log_index | /var/lib/mysql/relay-mysql.index |
| relay_log_info_file | relay-log.info |
| relay_log_info_repository | FILE |
| relay_log_purge | ON |
| relay_log_recovery | ON |
| relay_log_space_limit | 0 |
| sync_relay_log | 10000 |
| sync_relay_log_info | 10000 |
+---------------------------+----------------------------------+
max_relay_log_size：relay log允許的最大值，如果該值為0，則預設值為max_binlog_size (1G)。如果不為0，則max_relay_log_size則為最大的relay_log檔案大小；
relay_log: 定義relay_log的位置和名稱，如果值為空，則預設位置在資料檔案的目錄；
relay_log_index：定義relay_log索引的位置和名稱，記錄有幾個relay_log檔案，預設為2個
cat /var/lib/mysql/relay-mysql.index
#結果
./relay-mysql.000241
./relay-mysql.000242
relay_log_info_file：定義relay-log.info的位置和名稱。relay-log.info記錄master主庫的binary_log的恢復位置和從庫relay_log的位置；
[root@localhost ~]# cat /var/lib/mysql/relay-log.info
#結果
7
./relay-mysql.000242
19421766
mysql-bin.000094
34300252
0
0
1
relay_log_purge：是否自動清空中繼日誌，預設值為1(啟用)；
relay_log_recovery：
當slave從庫當機後，假如relay-log損壞了，導致一部分中繼日誌沒有處理，則自動放棄所有未執行的relay-log，並且重新從master上獲取日誌，這樣就保證了relay-log的完整性。預設情況下該功能是關閉的，將relay_log_recovery的值設定為1時，可在slave從庫上開啟該功能，建議開啟；
sync_relay_log：當設定為1時，slave的I/O執行緒每次接收到master傳送過來的binlog日誌都要寫入系統緩衝區，然後刷入relay log中繼日誌裡，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成磁碟的大量I/O。當設定為0時，並不是馬上就刷入中繼日誌裡，而是由作業系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁碟I/O操作。這個值預設是0，可動態修改；
sync_relay_log_info：這個引數和sync_relay_log引數一樣。
五、undo log
undo log主要有兩個作用：回滾和多版本控制MVCC
在資料修改的時候，不僅記錄了redo log，還記錄undo log，如果因為某些原因導致事務失敗或回滾了，可以用undo log進行回滾
undo log主要儲存的也是邏輯日誌，比如我們要insert一條資料了，那undo log會記錄的一條對應的delete日誌。我們要update一條記錄時，它會記錄一條對應相反的update記錄。
這也應該容易理解，畢竟回滾嘛，跟需要修改的操作相反就好，這樣就能達到回滾的目的。因為支援回滾操作，所以我們就能保證：“一個事務包含多個操作，這些操作要麼全部執行，要麼全都不執行”。【原子性】
因為undo log儲存著修改之前的資料，相當於一個前版本，MVCC實現的是讀寫不阻塞，讀的時候只要返回前一個版本的資料就行了。