MySQL 日志 主要包括二進制日志 binlog（歸檔日志）、事務日志 redo log（重做日志）和 undo log（復原日志）。
redo log
redo log 是InnoDB存儲引擎級别的日志，能支援MySQL實作崩潰恢複。
如果 MySQL執行個體挂了或當機了，重新開機時，InnoDB存儲引擎會使用redo log恢複資料。
MySQL 中資料是以頁為機關，你查詢一條記錄，會從硬碟把一頁的資料加載出來，加載出來的資料叫資料頁，會放入到 Buffer Pool 中。
後續的查詢都是先從 Buffer Pool 中找，沒有命中再去硬碟加載，減少硬碟 IO 開銷，提升性能。
更新表資料的時候，也是如此，發現 Buffer Pool 裡存在要更新的資料，就直接在 Buffer Pool 裡更新。
然後會把“在某個資料頁上做了什麼修改”記錄到重做日志緩存（redo log buffer）裡，接着刷盤到 redo log 檔案裡。
理想情況，事務一送出就會進行刷盤操作，但實際上，刷盤的時機是根據政策來進行的。
刷盤時機
InnoDB 存儲引擎為 redo log 的刷盤政策提供了 innodb_flush_log_at_trx_commit 參數，它支援三種政策：
● 0 ：設定為 0 的時候，表示每次事務送出時不進行刷盤操作
● 1 ：設定為 1 的時候，表示每次事務送出時都将進行刷盤操作（預設值）
● 2 ：設定為 2 的時候，表示每次事務送出時都隻把 redo log buffer 内容寫入 page cache
innodb_flush_log_at_trx_commit 參數預設為 1 ，也就是說當事務送出時會調用 fsync 對 redo
log 進行刷盤
另外，InnoDB 存儲引擎有一個背景線程，每隔1 秒，就會把 redo log buffer 中的内容寫到檔案系統緩存（page cache），然後調用 fsync 刷盤。
除了背景線程每秒1次的輪詢操作，還有一種情況，當 redo log buffer 占用的空間即将達到 innodb_log_buffer_size 一半的時候，背景線程會主動刷盤。
在個日志檔案組中還有兩個重要的屬性，分别是write pos、checkpoint
● write pos是目前記錄的位置，一邊寫一邊後移
● checkpoint 是目前要擦除的位置，也是往後推移
每次刷盤 redo log 記錄到日志檔案組中，write pos 位置就會後移更新。
每次 MySQL 加載日志檔案組恢複資料時，會清空加載過的
redo log 記錄，并把 checkpoint 後移更新。
write pos 和 checkpoint 之間的還空着的部分可以用來寫入新的 redo log 記錄。
如果 write pos 追上
checkpoint ，表示日志檔案組滿了，這時候不能再寫入新的
redo log 記錄，MySQL 得停下來，清空一些記錄，把 checkpoint 推進一下。
binlog
redo log 它是實體日志，記錄内容是“在某個資料頁上做了什麼修改”，屬于 InnoDB 存儲引擎。
而 binlog 是邏輯日志，記錄内容是語句的原始邏輯，類似于“update b set name = bb2”，屬于MySQL Server 層。
一般來說MySQL資料庫的資料備份、主備、主主、主從都需要依靠binlog來同步資料，保證資料一緻性。
寫入機制
binlog的寫入時機也非常簡單，事務執行過程中，先把日志寫到binlog cache，事務送出的時候，再把binlog
cache寫到binlog檔案中。
因為一個事務的binlog不能被拆開，無論這個事務多大，也要確定一次性寫入，是以系統會給每個線程配置設定一個塊記憶體作為binlog cache。
我們可以通過binlog_cache_size參數控制單個線程 binlog cache 大小，如果存儲内容超過了這個參數，就要暫存到磁盤（Swap）。
binlog日志刷盤流程如下
● 上圖的 write，是指把日志寫入到檔案系統的 page cache，并沒有把資料持久化到磁盤，是以速度比較快
● 上圖的 fsync，才是将資料持久化到磁盤的操作
write和fsync的時機，可以由參數sync_binlog控制，預設是0。
為0的時候，表示每次送出事務都隻write，由系統自行判斷什麼時候執行fsync。
雖然性能得到提升，但是機器當機，page cache裡面的 binglog 會丢失。
為了安全起見，可以設定為1，表示每次送出事務都會執行fsync，就如同binlog 日志刷盤流程一樣。
最後還有一種折中方式，可以設定為N(N>1)，表示每次送出事務都write，但累積N個事務後才fsync。
在出現IO瓶頸的場景裡，将sync_binlog設定成一個比較大的值，可以提升性能。
同樣的，如果機器當機，會丢失最近N個事務的binlog日志。
兩階段送出
redo log（重做日志）讓InnoDB存儲引擎擁有了崩潰恢複能力。
binlog（歸檔日志）保證了MySQL叢集架構的資料一緻性。
雖然它們都屬于持久化的保證，但是側重點不同。
在執行更新語句過程，會記錄redo log與binlog兩塊日志，以基本的事務為機關，redo log在事務執行過程中可以不斷寫入，而binlog隻有在送出事務時才寫入，是以redo log與binlog的寫入時機不一樣。
redo log與binlog兩份日志可能存在不一緻的情況。
假設我們執行SQL語句為update a set age=20 where id=6。
寫完redo log日志後，binlog日志寫期間發生了異常，會出現什麼情況呢？
由于binlog沒寫完就異常，這時候binlog裡面沒有對應的修改記錄。是以，之後用binlog日志恢複資料時，就會少這一次更新，最終redolog 恢複的資料和 binlog恢複的資料會不一緻。
為了解決兩份日志之間的邏輯一緻問題，InnoDB存儲引擎使用兩階段送出方案。
原理很簡單，将redo log的寫入拆成了兩個步驟prepare和commit，這就是兩階段送出。
使用兩階段送出後，寫入binlog時發生異常也不會有影響，因為MySQL根據redo log日志恢複資料時，發現redo log還處于prepare階段，并且沒有對應binlog日志，就會復原該事務。
redo log設定commit階段發生異常，那會不會復原事務呢？
并不會復原事務，它會執行上圖框住的邏輯，雖然redo log是處于prepare階段，但是能通過事務id找到對應的binlog日志，是以MySQL認為是完整的，就會送出事務恢複資料。
undo log
如果想要保證事務的原子性，就需要在異常發生時，對已經執行的操作進行復原，在 MySQL 中，恢複機制是通過
復原日志（undo log） 實作的，所有事務進行的修改都會先記錄到這個復原日志中，然後再執行相關的操作。如果執行過程中遇到異常的話，我們直接利用
復原日志
中的資訊将資料復原到修改之前的樣子即可！并且，復原日志會先于資料持久化到磁盤上。這樣就保證了即使遇到資料庫突然當機等情況，當使用者再次啟動資料庫的時候，資料庫還能夠通過查詢復原日志來復原将之前未完成的事務。
通過binlog恢複資料demo
在開發過程中常存在誤删除，錯誤更新等情況。 這時候我們可以通過mysql的binlog日志恢複資料。
1. 首先确認開啟 mysql binlog 日志
修改mysql的配置檔案。linux是/etc/my.cnf，windows是mysql的安裝目錄/my.ini
在[mysqld]下面加上log-bin=mysql-bin 一行代碼。加完後重起mysql即可。
2. 進入 mysql, mysql -uroot -p
3. 檢視所有的二進制日志檔案 : show binary logs
4. 檢視test資料庫 b 表的資料 : select * from b;
5. 修改b資料表資料,id為2的資料 : update b set name = bb
where id = 2;
6. 格式化檢視binlog日志檔案 : show binlog events in ‘mysql-bin.000001‘ \G
從上圖中可以看到做修改的操作結束位置（end_log_pos）303
7. 推出mysql操作頁面， 通過指令恢複資料
mysqlbinlog --stop-position=302 /data/mysqldb/mysql-bin.000001
| grep mysql -uroot -p
指令含義:将302之前的所有事件操作重新執行一邊（不包括剛才的修改操作）
8. mysqlbinlog 相關指令的文法格式：
mysqlbinlog mysql-bin.0000xx | mysql -u使用者名 -p密碼 資料庫名
例：将302到500之間的所有事件操作重新執行一邊
mysqlbinlog --start-position=302
--stop-position=500 /data/mysqldb/mysql-bin.000001 | grep mysql -uroot -p
常用參數選項解釋：
--start-position=875 起始pos點
--stop-position=954 結束pos點
--start-datetime="2016-9-25 22:01:08"
起始時間點
--stop-datetime="2019-9-25 22:09:46" 結束時間點
--database=b指定隻恢複b資料庫(一台主機上往往有多個資料庫，隻限本地log日志)
不常用選項：
-u --user=name 連接配接到遠端主機的使用者名
-p --password[=name] 連接配接到遠端主機的密碼
-h --host=name 從遠端主機上擷取binlog日志
--read-from-remote-server 從某個MySQL伺服器上讀取binlog日志
總結
MySQL InnoDB 引擎使用 redo log(重做日志) 保證事務的持久性，使用 undo log(復原日志) 來保證事務的原子性。
MySQL資料庫的資料備份、主備、主主、主從都需要依靠binlog來同步資料，保證資料一緻性。