BinLog

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

STATEMENT 模式

內(nèi)容：binlog 只會(huì)記錄引起數(shù)據(jù)變更的 sql 語(yǔ)句

優(yōu)勢(shì)：該模式下，因?yàn)闆](méi)有記錄實(shí)際的數(shù)據(jù)，所以日志量和 IO 都消耗很低，性能是最優(yōu)的

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

ROW 模式

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

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

劣勢(shì)：缺點(diǎn)在于 binlog 體積會(huì)非常大，同時(shí)，對(duì)于修改記錄多、字段長(zhǎng)度大的操作來(lái)說(shuō)，記錄時(shí)性能消耗會(huì)很?chē)?yán)重。閱讀的時(shí)候也需要特殊指令來(lái)進(jìn)行讀取數(shù)據(jù)。

MIXED 模式

內(nèi)容：是對(duì)上述STATEMENT 跟 ROW 兩種模式的混合使用。

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

主從同步流程：

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

2、從節(jié)點(diǎn)開(kāi)啟一個(gè)線程（I/O Thread)把自己扮演成 mysql 的客戶(hù)端，通過(guò) mysql 協(xié)議，請(qǐng)求主節(jié)點(diǎn)的二進(jìn)制日志文件中的事件 。

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

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

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

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

• 全同步復(fù)制
  

主庫(kù)寫(xiě)入binlog后強(qiáng)制同步日志到從庫(kù)，所有的從庫(kù)都執(zhí)行完成后才返回給客戶(hù)端，但是很顯然這個(gè)方式的話性能會(huì)受到嚴(yán)重影響。

• 半同步復(fù)制

半同步復(fù)制的邏輯是這樣，從庫(kù)寫(xiě)入日志成功后返回ACK確認(rèn)給主庫(kù)，主庫(kù)收到至少一個(gè)從庫(kù)的確認(rèn)就認(rèn)為寫(xiě)操作完成。

RedoLog

binlog跟redolog區(qū)別：

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

在MySQL中如果每一次的更新操作都需要寫(xiě)進(jìn)磁盤(pán)，然后磁盤(pán)也要找到對(duì)應(yīng)的那條記錄，然后再更新，整個(gè)過(guò)程IO成本、查找成本都很高。先寫(xiě)日志，再寫(xiě)磁盤(pán)BinLog，RedoLog。

1、 記錄更新時(shí)，InnoDB引擎就會(huì)先把記錄寫(xiě)到RedoLog（里面，并更新內(nèi)存。同時(shí)，InnoDB引擎會(huì)在空閑時(shí)將這個(gè)操作記錄更新到磁盤(pán)里面。

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

RedoLog的write pos 跟checkpoint

RedoLog有write pos 跟checkpoint

write pos ：是當(dāng)前記錄的位置，一邊寫(xiě)一邊后移，寫(xiě)到第3號(hào)文件末尾后就回到0號(hào)文件開(kāi)頭。

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

redo log順序?qū)憣?shí)際上是循環(huán)寫(xiě)固定幾個(gè)文件，寫(xiě)滿(mǎn)一輪就要從頭開(kāi)始覆蓋。它包括兩個(gè)位點(diǎn)，check point和write pos，write pos是寫(xiě)到那個(gè)位置了，循環(huán)往后遞增，check point是當(dāng)前要擦除的位置。二者中間的空間是可寫(xiě)入的，當(dāng)write pos追上check point時(shí)，就會(huì)先停下更新，覆蓋掉一些記錄，然后繼續(xù)寫(xiě)入redo log。

redo log 的crash-safe

MySQL支持用戶(hù)自定義在commit時(shí)如何將log buffer中的日志刷log file中。這種控制通過(guò)變量 innodb_flush_log_at_trx_commit 的值來(lái)決定。該變量有3種值：0、1、2，默認(rèn)為1。但注意，這個(gè)變量只是控制commit動(dòng)作是否刷新log buffer到磁盤(pán)。

• 當(dāng)設(shè)置為1的時(shí)候，事務(wù)每次提交都會(huì)將log buffer中的日志寫(xiě)入os buffer并調(diào)用fsync()刷到log file on disk中。這種方式即使系統(tǒng)崩潰也不會(huì)丟失任何數(shù)據(jù)，但是因?yàn)槊看翁峤欢紝?xiě)入磁盤(pán)，IO的性能較差。
• 當(dāng)設(shè)置為0的時(shí)候，事務(wù)提交時(shí)不會(huì)將log buffer中日志寫(xiě)入到os buffer，而是每秒寫(xiě)入os buffer并調(diào)用fsync()寫(xiě)入到log file on disk中。也就是說(shuō)設(shè)置為0時(shí)是(大約)每秒刷新寫(xiě)入到磁盤(pán)中的，當(dāng)系統(tǒng)崩潰，會(huì)丟失1秒鐘的數(shù)據(jù)。
• 當(dāng)設(shè)置為2的時(shí)候，每次提交都僅寫(xiě)入到os buffer，然后是每秒調(diào)用fsync()將os buffer中的日志寫(xiě)入到log file on disk。

在主從復(fù)制結(jié)構(gòu)中，要保證事務(wù)的持久性和一致性，需要對(duì)日志相關(guān)變量設(shè)置為如下：

• 如果啟用了二進(jìn)制日志，則設(shè)置sync_binlog=1，即每提交一次事務(wù)同步寫(xiě)到磁盤(pán)中。
• 總是設(shè)置innodb_flush_log_at_trx_commit=1，即每提交一次事務(wù)都寫(xiě)到磁盤(pán)中。

上述兩項(xiàng)變量的設(shè)置保證了：每次提交事務(wù)都寫(xiě)入二進(jìn)制日志和事務(wù)日志，并在提交時(shí)將它們刷新到磁盤(pán)中。

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

1 prepare階段 --> 2 寫(xiě)binlog --> 3 commit

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

UndoLog

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

在數(shù)據(jù)修改的時(shí)候，不僅記錄了redo，還記錄了相對(duì)應(yīng)的undo，如果因?yàn)槟承┰驅(qū)е率聞?wù)失敗或回滾了，可以借助該undo進(jìn)行回滾。當(dāng)delete一條記錄時(shí)，undo log中會(huì)記錄一條對(duì)應(yīng)的insert記錄，反之亦然，當(dāng)update一條記錄時(shí)，它記錄一條對(duì)應(yīng)相反的update記錄。

當(dāng)執(zhí)行rollback時(shí)，就可以從undo log中的邏輯記錄讀取到相應(yīng)的內(nèi)容并進(jìn)行回滾

• insert undo log
  

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

• update undo log
  

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

以上就是MySQL 主從同步,事務(wù)回滾的實(shí)現(xiàn)原理的詳細(xì)內(nèi)容，更多關(guān)于MySQL 主從同步,事務(wù)回滾的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！