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確認給主庫，主庫收到至少一個從庫的確認就認為寫操作完成。

RedoLogbinlog跟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 主從同步,事務回滾的資料請關注好吧啦網其它相關文章！