BinLog

BinLog是記錄所有資料庫表結構變更（例如create、alter table）以及表資料修改(insert、update、delete)的二進位制日誌，主從資料庫同步用到的都是BinLog檔案。BinLog日誌檔案有三種模式。

STATEMENT 模式

內容：binlog 只會記錄引起資料變更的 sql 語句

優勢：該模式下，因為沒有記錄實際的資料，所以日誌量和 IO 都消耗很低，效能是最優的

劣勢：但有些操作並不是確定的，比如 uuid() 函式會隨機產生唯一標識，當依賴 binlog 回放時，該操作生成的資料與原資料必然是不同的，此時可能造成無法預料的後果。

ROW 模式

內容：在該模式下，binlog 會記錄每次操作的源資料與修改後的目標資料，StreamSets就要求該模式。

優勢：可以絕對精準的還原，從而保證了資料的安全與可靠，並且複製和資料恢復過程可以是併發進行的

劣勢：缺點在於 binlog 體積會非常大，同時，對於修改記錄多、欄位長度大的操作來說，記錄時效能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取資料。

MIXED 模式

內容：是對上述STATEMENT 跟 ROW 兩種模式的混合使用。

細節：對於絕大部分操作，都使用 STATEMENT 來進行 binlog 的記錄，只有以下操作使用 ROW 來實現：表的儲存引擎為 NDB，使用了uuid() 等不確定函式，使用了 insert delay 語句，使用了臨時表

主從同步流程：

1、主節點必須啟用二進位制日誌，記錄任何修改了資料庫資料的事件。

2、從節點開啟一個執行緒（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協議，請求主節點的二進位制日誌檔案中的事件 。

3、主節點啟動一個執行緒（dump Thread），檢查自己二進位制日誌中的事件，跟對方請求的位置對比，如果不帶請求位置引數，則主節點就會從第一個日誌檔案中的第一個事件一個一個傳送給從節點。

4、從節點接收到主節點發送過來的資料把它放置到中繼日誌（Relay log）檔案中。並記錄該次請求到主節點的具體哪一個二進位制日誌檔案內部的哪一個位置（主節點中的二進位制檔案會有多個）。

5、從節點啟動另外一個執行緒（sql Thread ），把 Relay log 中的事件讀取出來，並在本地再執行一次。

mysql預設的複製方式是非同步的，並且複製的時候是有並行複製能力的。主庫把日誌傳送給從庫後不管了，這樣會產生一個問題就是假設主庫掛了，從庫處理失敗了，這時候從庫升為主庫後，日誌就丟失了。由此產生兩個概念。

• 全同步複製
  

主庫寫入binlog後強制同步日誌到從庫，所有的從庫都執行完成後才返回給客戶端，但是很顯然這個方式的話效能會受到嚴重影響。

• 半同步複製

半同步複製的邏輯是這樣，從庫寫入日誌成功後返回ACK確認給主庫，主庫收到至少一個從庫的確認就認為寫操作完成。

RedoLog

binlog跟redolog區別：

• redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現的，所有引擎都可以使用。
• redo log是物理日誌，記錄的是在某個資料頁上做了什麼修改；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c欄位加1。
• redo log是迴圈寫的，空間固定會用完；binlog是可以追加寫入的。追加寫是指binlog檔案寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。

在MySQL中如果每一次的更新操作都需要寫進磁碟，然後磁碟也要找到對應的那條記錄，然後再更新，整個過程IO成本、查詢成本都很高。先寫日誌，再寫磁碟BinLog，RedoLog。

1、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（裡面，並更新記憶體。同時，InnoDB引擎會在空閒時將這個操作記錄更新到磁盤裡面。

2、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分資料寫到磁碟，然後擦除RedoLog部分資料。

RedoLog的write pos 跟checkpoint

RedoLog有write pos 跟checkpoint

write pos ：是當前記錄的位置，一邊寫一邊後移，寫到第3號檔案末尾後就回到0號檔案開頭。

check point：縮短資料庫的恢復時間，buffer pool空間不夠用時，將髒頁重新整理到磁碟，redolog不可用時，重新整理髒頁

redo log順序寫實際上是迴圈寫固定幾個檔案，寫滿一輪就要從頭開始覆蓋。它包括兩個位點，check point和write pos，write pos是寫到那個位置了，迴圈往後遞增，check point是當前要擦除的位置。二者中間的空間是可寫入的，當write pos追上check point時，就會先停下更新，覆蓋掉一些記錄，然後繼續寫入redo log。

redo log 的crash-safe

MySQL支援使用者自定義在commit時如何將log buffer中的日誌刷log file中。這種控制通過變數 innodb_flush_log_at_trx_commit 的值來決定。該變數有3種值：0、1、2，預設為1。但注意，這個變數只是控制commit動作是否重新整理log buffer到磁碟。

• 當設定為1的時候，事務每次提交都會將log buffer中的日誌寫入os buffer並呼叫fsync()刷到log file on disk中。這種方式即使系統崩潰也不會丟失任何資料，但是因為每次提交都寫入磁碟，IO的效能較差。
• 當設定為0的時候，事務提交時不會將log buffer中日誌寫入到os buffer，而是每秒寫入os buffer並呼叫fsync()寫入到log file on disk中。也就是說設定為0時是(大約)每秒重新整理寫入到磁碟中的，當系統崩潰，會丟失1秒鐘的資料。
• 當設定為2的時候，每次提交都僅寫入到os buffer，然後是每秒呼叫fsync()將os buffer中的日誌寫入到log file on disk。

在主從複製結構中，要保證事務的永續性和一致性，需要對日誌相關變數設定為如下：

• 如果啟用了二進位制日誌，則設定sync_binlog=1，即每提交一次事務同步寫到磁碟中。
• 總是設定innodb_flush_log_at_trx_commit=1，即每提交一次事務都寫到磁碟中。

上述兩項變數的設定保證了：每次提交事務都寫入二進位制日誌和事務日誌，並在提交時將它們重新整理到磁碟中。

有了redo log，InnoDB就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。redolog兩階段提交`：為了讓binlog跟redolog兩份日誌之間的邏輯一致。提交流程大致如下：

1 prepare階段 --> 2 寫binlog --> 3 commit

1.當在2之前崩潰時，重啟恢復後發現沒有commit，回滾。備份恢復：沒有binlog 。一致
2.當在3之前崩潰時，重啟恢復發現雖沒有commit，但滿足prepare和binlog完整，所以重啟後會自動commit。備份：有binlog. 一致

UndoLog

undo log有兩個作用：提供回滾和多個行版本控制(MVCC).主要分為兩種

在資料修改的時候，不僅記錄了redo，還記錄了相對應的undo，如果因為某些原因導致事務失敗或回滾了，可以藉助該undo進行回滾。當delete一條記錄時，undo log中會記錄一條對應的insert記錄，反之亦然，當update一條記錄時，它記錄一條對應相反的update記錄。

當執行rollback時，就可以從undo log中的邏輯記錄讀取到相應的內容並進行回滾

• insert undo log
  

代表事務在insert新記錄時產生的undo log,只在事務回滾時需要，並且在事務提交後可以被立即丟棄

• update undo log
  

事務在進行update或delete時產生的undo log; 不僅在事務回滾時需要，在快照讀時也需要；所以不能隨便刪除，只有在快速讀或事務回滾不涉及該日誌時，對應的日誌才會被purge執行緒統一清除

以上就是MySQL 主從同步,事務回滾的實現原理的詳細內容，更多關於MySQL 主從同步,事務回滾的資料請關注我們其它相關文章！