本文讀完需3分鐘，速讀僅需1分鐘。

前言

阿星在前面兩篇文章都詳細(xì)聊過redo log與binlog，有興趣的朋友可以去看看前面兩篇文章：

聊聊redo log是什么？
你必須知道的binlog日志

今天就來聊聊InnoDB是如何保證redo log與binlog兩份日志之間的邏輯一致。

兩階段提交

redo log（重做日志）讓InnoDB存儲引擎擁有了崩潰恢復(fù)能力。

binlog（歸檔日志）保證了MySQL集群架構(gòu)的數(shù)據(jù)一致性。

雖然它們都屬于持久化的保證，但是則重點(diǎn)不同。

在執(zhí)行更新語句過程，會記錄redo log與binlog兩塊日志，以基本的事務(wù)為單位，redo log在事務(wù)執(zhí)行過程中可以不斷寫入，而binlog只有在提交事務(wù)時才寫入，所以redo log與binlog的寫入時機(jī)不一樣。

回到正題，redo log與binlog兩份日志之間的邏輯不一致，會出現(xiàn)什么問題？

我們以update語句為例，假設(shè)id=2的記錄，字段c值是0，把字段c值更新成1，SQL語句為update T set c=1 where id=2。

假設(shè)執(zhí)行過程中寫完redo log日志后，binlog日志寫期間發(fā)生了異常，會出現(xiàn)什么情況呢？

由于binlog沒寫完就異常，這時候binlog里面沒有對應(yīng)的修改記錄。因此，之后用binlog日志恢復(fù)數(shù)據(jù)時，就會少這一次更新，恢復(fù)出來的這一行c值是0，而原庫因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(255, 100, 65);">redo log日志恢復(fù)，這一行c值是1，最終數(shù)據(jù)不一致。

為了解決兩份日志之間的邏輯一致問題，InnoDB存儲引擎使用兩階段提交方案。

原理很簡單，將redo log的寫入拆成了兩個步驟prepare和commit，這就是兩階段提交。

使用兩階段提交后，寫入binlog時發(fā)生異常也不會有影響，因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(255, 100, 65);">MySQL根據(jù)redo log日志恢復(fù)數(shù)據(jù)時，發(fā)現(xiàn)redo log還處于prepare階段，并且沒有對應(yīng)binlog日志，就會回滾該事務(wù)。