BinLog

BinLog是記錄所有數(shù)據(jù)庫表結構變更（例如create、alter table）以及表數(shù)據(jù)修改(insert、update、delete)的二進制日志，主從數(shù)據(jù)庫同步用到的都是BinLog文件。BinLog日志文件有三種模式。

STATEMENT 模式

內容：binlog 只會記錄引起數(shù)據(jù)變更的 sql 語句

優(yōu)勢：該模式下，因為沒有記錄實際的數(shù)據(jù)，所以日志量和 IO 都消耗很低，性能是最優(yōu)的

劣勢：但有些操作并不是確定的，比如 uuid() 函數(shù)會隨機產(chǎn)生唯一標識，當依賴 binlog 回放時，該操作生成的數(shù)據(jù)與原數(shù)據(jù)必然是不同的，此時可能造成無法預料的后果。

ROW 模式

內容：在該模式下，binlog 會記錄每次操作的源數(shù)據(jù)與修改后的目標數(shù)據(jù)，StreamSets就要求該模式。

優(yōu)勢：可以絕對精準的還原，從而保證了數(shù)據(jù)的安全與可靠，并且復制和數(shù)據(jù)恢復過程可以是并發(fā)進行的

劣勢：缺點在于 binlog 體積會非常大，同時，對于修改記錄多、字段長度大的操作來說，記錄時性能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取數(shù)據(jù)。

MIXED 模式

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

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

主從同步流程：

1、主節(jié)點必須啟用二進制日志，記錄任何修改了數(shù)據(jù)庫數(shù)據(jù)的事件。

2、從節(jié)點開啟一個線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協(xié)議，請求主節(jié)點的二進制日志文件中的事件 。

3、主節(jié)點啟動一個線程（dump Thread），檢查自己二進制日志中的事件，跟對方請求的位置對比，如果不帶請求位置參數(shù)，則主節(jié)點就會從第一個日志文件中的第一個事件一個一個發(fā)送給從節(jié)點。

4、從節(jié)點接收到主節(jié)點發(fā)送過來的數(shù)據(jù)把它放置到中繼日志（Relay log）文件中。并記錄該次請求到主節(jié)點的具體哪一個二進制日志文件內部的哪一個位置（主節(jié)點中的二進制文件會有多個）。

5、從節(jié)點啟動另外一個線程（sql Thread ），把 Relay log 中的事件讀取出來，并在本地再執(zhí)行一次。

mysql默認的復制方式是異步的，并且復制的時候是有并行復制能力的。主庫把日志發(fā)送給從庫后不管了，這樣會產(chǎn)生一個問題就是假設主庫掛了，從庫處理失敗了，這時候從庫升為主庫后，日志就丟失了。由此產(chǎn)生兩個概念。

全同步復制

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

半同步復制

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

RedoLogbinlog跟redolog區(qū)別： redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現(xiàn)的，所有引擎都可以使用。 redo log是物理日志，記錄的是在某個數(shù)據(jù)頁上做了什么修改；binlog是邏輯日志，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c字段加1。 redo log是循環(huán)寫的，空間固定會用完；binlog是可以追加寫入的。追加寫是指binlog文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。

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

1、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（里面，并更新內存。同時，InnoDB引擎會在空閑時將這個操作記錄更新到磁盤里面。

2、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分數(shù)據(jù)寫到磁盤，然后擦除RedoLog部分數(shù)據(jù)。

RedoLog的write pos 跟checkpoint

RedoLog有write pos 跟checkpoint

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

check point：縮短數(shù)據(jù)庫的恢復時間，buffer pool空間不夠用時，將臟頁刷新到磁盤，redolog不可用時，刷新臟頁

redo log順序寫實際上是循環(huán)寫固定幾個文件，寫滿一輪就要從頭開始覆蓋。它包括兩個位點，check point和write pos，write pos是寫到那個位置了，循環(huán)往后遞增，check point是當前要擦除的位置。二者中間的空間是可寫入的，當write pos追上check point時，就會先停下更新，覆蓋掉一些記錄，然后繼續(xù)寫入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中。這種方式即使系統(tǒng)崩潰也不會丟失任何數(shù)據(jù)，但是因為每次提交都寫入磁盤，IO的性能較差。 當設置為0的時候，事務提交時不會將log buffer中日志寫入到os buffer，而是每秒寫入os buffer并調用fsync()寫入到log file on disk中。也就是說設置為0時是(大約)每秒刷新寫入到磁盤中的，當系統(tǒng)崩潰，會丟失1秒鐘的數(shù)據(jù)。 當設置為2的時候，每次提交都僅寫入到os buffer，然后是每秒調用fsync()將os buffer中的日志寫入到log file on disk。

在主從復制結構中，要保證事務的持久性和一致性，需要對日志相關變量設置為如下：

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

上述兩項變量的設置保證了：每次提交事務都寫入二進制日志和事務日志，并在提交時將它們刷新到磁盤中。

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

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

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

UndoLog

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

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

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

insert undo log

代表事務在insert新記錄時產(chǎn)生的undo log, 只在事務回滾時需要，并且在事務提交后可以被立即丟棄

update undo log

事務在進行update或delete時產(chǎn)生的undo log; 不僅在事務回滾時需要，在快照讀時也需要；所以不能隨便刪除，只有在快速讀或事務回滾不涉及該日志時，對應的日志才會被purge線程統(tǒng)一清除

以上就是MySQL 主從同步,事務回滾的實現(xiàn)原理的詳細內容，更多關于MySQL 主從同步,事務回滾的資料請關注好吧啦網(wǎng)其它相關文章！