一文看懂MySQL的異步復(fù)制、全同步復(fù)制與半同步復(fù)制
今天主要聊一下MySQL的異步復(fù)制、全同步復(fù)制與半同步復(fù)制，目前我們生產(chǎn)庫(kù)實(shí)際上用的就是異步復(fù)制了，后面再轉(zhuǎn)成半同步復(fù)制。
一、MYSQL復(fù)制架構(gòu)衍生史
在2000年，MySQL 3.23.15版本引入了Replication。Replication作為一種準(zhǔn)實(shí)時(shí)同步方式，得到廣泛應(yīng)用。這個(gè)時(shí)候的Replicaton的實(shí)現(xiàn)涉及到兩個(gè)線程，一個(gè)在Master，一個(gè)在Slave。Slave的I/O和SQL功能是作為一個(gè)線程，從Master獲取到event后直接apply，沒有relay log。這種方式使得讀取event的速度會(huì)被Slave replay速度拖慢，當(dāng)主備存在較大延遲時(shí)候，會(huì)導(dǎo)致大量binary log沒有備份到Slave端。
在2002年，MySQL 4.0.2版本將Slave端event讀取和執(zhí)行獨(dú)立成兩個(gè)線程(IO線程和SQL線程)，同時(shí)引入了relay log。IO線程讀取event后寫入relay log，SQL線程從relay log中讀取event然后執(zhí)行。這樣即使SQL線程執(zhí)行慢，Master的binary log也會(huì)盡可能的同步到Slave。當(dāng)Master宕機(jī)，切換到Slave，不會(huì)出現(xiàn)大量數(shù)據(jù)丟失。
在2010年MySQL 5.5版本之前，一直采用的是這種異步復(fù)制的方式。主庫(kù)的事務(wù)執(zhí)行不會(huì)管備庫(kù)的同步進(jìn)度，如果備庫(kù)落后，主庫(kù)不幸crash，那么就會(huì)導(dǎo)致數(shù)據(jù)丟失。于是在MySQL在5.5中就順其自然地引入了半同步復(fù)制，主庫(kù)在應(yīng)答客戶端提交的事務(wù)前需要保證至少一個(gè)從庫(kù)接收并寫到relay log中。
在2016年，MySQL在5.7.17中引入了一個(gè)全新的技術(shù)，稱之為InnoDB Group Replication。目前官方MySQL 5.7.17基于Group replication的全同步技術(shù)已經(jīng)問世，全同步技術(shù)帶來了更多的數(shù)據(jù)一致性保障。
下圖對(duì)應(yīng)MySQL幾種復(fù)制類型，分別是異步、半同步、全同步
二、異步復(fù)制(Asynchronous replication)
1. 邏輯上
MySQL默認(rèn)的復(fù)制即是異步的，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后會(huì)立即將結(jié)果返給給客戶端，并不關(guān)心從庫(kù)是否已經(jīng)接收并處理，這樣就會(huì)有一個(gè)問題，主如果crash掉了，此時(shí)主上已經(jīng)提交的事務(wù)可能并沒有傳到從庫(kù)上，如果此時(shí)，強(qiáng)行將從提升為主，可能導(dǎo)致新主上的數(shù)據(jù)不完整。
2. 技術(shù)上
主庫(kù)將事務(wù) Binlog 事件寫入到 Binlog 文件中，此時(shí)主庫(kù)只會(huì)通知一下 Dump 線程發(fā)送這些新的 Binlog，然后主庫(kù)就會(huì)繼續(xù)處理提交操作，而此時(shí)不會(huì)保證這些 Binlog 傳到任何一個(gè)從庫(kù)節(jié)點(diǎn)上。
3. 原理圖
(1) 在Slave 服務(wù)器上執(zhí)行sart slave命令開啟主從復(fù)制開關(guān)，開始進(jìn)行主從復(fù)制。
(2) 此時(shí)，Slave服務(wù)器的IO線程會(huì)通過在master上已經(jīng)授權(quán)的復(fù)制用戶權(quán)限請(qǐng)求連接master服務(wù)器，并請(qǐng)求從執(zhí)行binlog日志文件的指定位置(日志文件名和位置就是在配置主從復(fù)制服務(wù)時(shí)執(zhí)行change master命令指定的)之后開始發(fā)送binlog日志內(nèi)容
(3) Master服務(wù)器接收到來自Slave服務(wù)器的IO線程的請(qǐng)求后，其上負(fù)責(zé)復(fù)制的IO線程會(huì)根據(jù)Slave服務(wù)器的IO線程請(qǐng)求的信息分批讀取指定binlog日志文件指定位置之后的binlog日志信息，然后返回給Slave端的IO線程。返回的信息中除了binlog日志內(nèi)容外，還有在Master服務(wù)器端記錄的IO線程。返回的信息中除了binlog中的下一個(gè)指定更新位置。
(4) 當(dāng)Slave服務(wù)器的IO線程獲取到Master服務(wù)器上IO線程發(fā)送的日志內(nèi)容、日志文件及位置點(diǎn)后，會(huì)將binlog日志內(nèi)容依次寫到Slave端自身的Relay Log(即中繼日志)文件(Mysql-relay-bin.xxx)的最末端，并將新的binlog文件名和位置記錄到master-info文件中，以便下一次讀取master端新binlog日志時(shí)能告訴Master服務(wù)器從新binlog日志的指定文件及位置開始讀取新的binlog日志內(nèi)容
(5) Slave服務(wù)器端的SQL線程會(huì)實(shí)時(shí)檢測(cè)本地Relay Log 中IO線程新增的日志內(nèi)容，然后及時(shí)把Relay LOG 文件中的內(nèi)容解析成sql語(yǔ)句，并在自身Slave服務(wù)器上按解析SQL語(yǔ)句的位置順序執(zhí)行應(yīng)用這樣sql語(yǔ)句，并在relay-log.info中記錄當(dāng)前應(yīng)用中繼日志的文件名和位置點(diǎn)
三、全同步復(fù)制(Fully synchronous replication)
1. 邏輯上
指當(dāng)主庫(kù)執(zhí)行完一個(gè)事務(wù)，所有的從庫(kù)都執(zhí)行了該事務(wù)才返回給客戶端。因?yàn)樾枰却袕膸?kù)執(zhí)行完該事務(wù)才能返回，所以全同步復(fù)制的性能必然會(huì)收到嚴(yán)重的影響。
2. 技術(shù)上
當(dāng)主庫(kù)提交事務(wù)之后，所有的從庫(kù)節(jié)點(diǎn)必須收到、APPLY并且提交這些事務(wù)，然后主庫(kù)線程才能繼續(xù)做后續(xù)操作。但缺點(diǎn)是，主庫(kù)完成一個(gè)事務(wù)的時(shí)間會(huì)被拉長(zhǎng)，性能降低。
3. 原理圖
四、半同步復(fù)制(Semisynchronous replication)
1. 邏輯上
是介于全同步復(fù)制與全異步復(fù)制之間的一種，主庫(kù)只需要等待至少一個(gè)從庫(kù)節(jié)點(diǎn)收到并且 Flush Binlog 到 Relay Log 文件即可，主庫(kù)不需要等待所有從庫(kù)給主庫(kù)反饋。同時(shí)，這里只是一個(gè)收到的反饋，而不是已經(jīng)完全完成并且提交的反饋，如此，節(jié)省了很多時(shí)間。
2. 技術(shù)上
介于異步復(fù)制和全同步復(fù)制之間，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫(kù)接收到并寫到relay log中才返回給客戶端。相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時(shí)它也造成了一定程度的延遲，這個(gè)延遲最少是一個(gè)TCP/IP往返的時(shí)間。所以，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。
3. 原理圖
master將每個(gè)事務(wù)寫入binlog(sync_binlog=1)，傳遞到slave刷新到磁盤(sync_relay=1)，同時(shí)主庫(kù)提交事務(wù)(commit)。master等待slave反饋收到relay log，只有收到ACK后master才將commit OK結(jié)果反饋給客戶端。
總之，mysql主從模式默認(rèn)是異步復(fù)制的，而MySQL Cluster是同步復(fù)制的，只要設(shè)置為相應(yīng)的模式即是在使用相應(yīng)的同步策略。
從MySQL5.5開始，MySQL以插件的形式支持半同步復(fù)制。其實(shí)說明半同步復(fù)制是更好的方式，兼顧了同步和性能的問題。
