MySQL邏輯架構大致可以分為兩層：
- 服務層：MySQL的核心服務功能佩微，包括查詢語句解析稿黄，詞法語法分析喊衫，優(yōu)化，緩存以及內置函數(日期杆怕，時間族购，數學，加密等)陵珍，跨存儲引擎的功能：存儲過程寝杖，觸發(fā)器，視圖等互纯。
- 存儲引擎：負責MySQL中數據的存儲和提取瑟幕。
我們知道在MySQL中，server層的日志，成為binlog(歸檔日志)只盹，主要用來做主從復置和恢復時使用的辣往。redo log是InnoDB引擎的日志，來實現crash-safe能力殖卑。
為什么會有兩份日志呢站削？
因為MySQL早期版本中沒有InnoDB引擎，MySQL自帶的引擎是MyISAM孵稽，MyISAM是沒有crash-safe能力的许起，直到將InnoDB以插件的形式引入，InnoDB使用Redo Log來實現crash-safe能力菩鲜。
binlog和Redo Log主要有以下三點不同:
- Redo Log是InnoDB引擎特有的园细；binlog是MySQL的server層實現的，不管哪種引擎接校，都會有binlog猛频。
- Redo Log是物理日志，記錄數據是怎么變化的馅笙；binlog是邏輯日志伦乔，記錄的是語句的邏輯操作。
- Redo Log是循環(huán)寫的董习，空間固定會用完；binlog是追加寫入的爱只，文件寫到一定大小后會切換到下一個皿淋，并不會覆蓋以前的日志。
InnoDB如何保證crash-safe恬试，MySQL服務器宕機重啟后：
- 所有已經提交的事務的數據仍然存在
- 所有沒有提交的事務的數據自動回滾
InnoDB通過Redo Log和Undo Log保證以上兩點窝趣。在每個事務提交的時候，將Redo Log寫入硬件存儲训柴，這樣做會犧牲一些性能哑舒，但是可靠性最好。為了平衡兩者幻馁，InnoDB提供了一個innodb_flush_log_at_trx_commit系統(tǒng)變量洗鸵，用戶可以根據應用的需求自行調整。通過redo日志將所有已經提交的事務恢復仗嗦，已經prepare但是沒有commit的事務將會應用undo log做rollback膘滨。
在更新數據時，先寫日志稀拐，再寫磁盤火邓，就是所謂的WAL技術(Write-Ahead Logging)。InnoDB引擎先把記錄寫到Redo Log中，再更新內存铲咨，這個時候認為更新就完成了躲胳。InnoDB引擎會在適當的時候，將這個記錄更新到磁盤里面纤勒，一般會在系統(tǒng)比較空閑的時候坯苹。
為保證數據的一致性，就必須保證binlog和Redo Log的一致性踊东，MySQL引入兩階段提交(two phase commit or 2pc)北滥，來保證數據一致性。具體做法是將Redo log的寫入拆成了兩個步驟:prepare和commit闸翅，這就是所謂的"兩階段提交”再芋。
在主從復制場景下，MySQL內部會自動將普通事務當作一個XA事務(內部分布式事務)來處理：
- 自動為每個事務分配一個唯一的ID（XID）
- COMMIT會被自動的分成Prepare和Commit兩個階段
- Binlog會被當做事務協(xié)調者（Transaction Coordinator）坚冀，Binlog Event會被當做協(xié)調者日志
Binlog在2PC中充當了事務的協(xié)調者（Transaction Coordinator）济赎。由Binlog來通知InnoDB引擎來執(zhí)行prepare，commit或者rollback的步驟记某。事務提交的整個過程如下：
分析此圖司训，當事務提交時（執(zhí)行commit語句），分別對應以下幾個階段：
協(xié)調者準備階段（Prepare Phase）
此時SQL已經成功執(zhí)行了液南，已經產生了語句的redo和undo內存日志壳猜，已經進入了事務commit步驟。然后告訴引擎做Prepare完成第一階段滑凉，Prepare階段就是寫Prepare Log（Prepare Log也是Redo Log）统扳，將事務狀態(tài)設為TRX_PREPARED，寫Prepare XID（事務ID號）到Redo Log畅姊。寫XID到Redo Log的時候會一并把Redo Log刷新到磁盤咒钟，這個時候Redo Log的日志量大小取決于執(zhí)行SQL語句時產生的Redo是否被刷盤，這個刷盤是隨機的若未，后臺Master線程每秒鐘都會刷新一次朱嘴。協(xié)調者提交階段（Commit Phase）
2.1 記錄協(xié)調者日志，即Binlog日志
如果事務涉及的所有存儲引擎的Prepare都執(zhí)行成功粗合，則調用TC_LOG_BINLOG::log_xid方法將SQL語句寫到Binlog（write()將binary log內存日志數據寫入文件系統(tǒng)緩存萍嬉，fsync()將binary log文件系統(tǒng)緩存日志數據永久寫入磁盤），同時也會把XID寫入到Binlog舌劳。此時帚湘，事務已經鐵定要提交了。否則甚淡，調用ha_rollback_trans方法回滾事務大诸，而SQL語句實際上也不會寫到binlog捅厂。
2.2 告訴引擎做Commit
最后，調用引擎的Commit完成事務的提交资柔。并且會對事務的undo log從prepare狀態(tài)設置為提交狀態(tài)（可清理狀態(tài)）焙贷，刷新Commit Log到Redo Log，釋放鎖贿堰，釋放mvcc相關的read view等等辙芍；將事務設為TRX_NOT_STARTED狀態(tài)。
記錄Binlog是在InnoDB引擎Prepare（即Redo Log寫入磁盤）之后羹与，這點至關重要故硅。另外需要注意的一點就是，SQL語句產生的Redo日志會一直刷新到磁盤（master thread每秒fsync redo log）纵搁，而Binlog是事務commit時才刷新到磁盤吃衅，如果binlog太大則commit時會慢。
由上面的二階段提交流程可以看出腾誉，通過兩階段提交方式保證了無論在任何情況下徘层，事務要么同時存在于存儲引擎和binlog中，要么兩個里面都不存在利职，可以保證事務的binlog和redo log順序一致性趣效。一旦階段2中持久化Binlog完成，就確保了事務的提交猪贪。此外需要注意的是跷敬，每個階段都需要進行一次fsync操作才能保證上下兩層數據的一致性。階段1的fsync由參數innodb_flush_log_at_trx_commit=1控制热押，階段2的fsync由參數sync_binlog=1控制干花，俗稱“雙1”，是保證crash-safe的根本楞黄。
