快捷導(dǎo)航

關(guān)于MySQL主從復(fù)制的幾種復(fù)制方式總結(jié)

更新時(shí)間：2020年08月16日 16:08:44 作者：itbsl

這篇文章主要給大家介紹了關(guān)于MySQL主從復(fù)制的幾種復(fù)制方式，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧

異步復(fù)制

MySQL的復(fù)制默認(rèn)是異步的，主從復(fù)制至少需要兩個(gè)MYSQL服務(wù)，這些MySQL服務(wù)可以分布在不同的服務(wù)器上，也可以在同一臺(tái)服務(wù)器上。

MySQL主從異步復(fù)制是最常見(jiàn)的復(fù)制場(chǎng)景。數(shù)據(jù)的完整性依賴于主庫(kù)BINLOG的不丟失，只要主庫(kù)的BINLOG不丟失，那么就算主庫(kù)宕機(jī)了，我們還可以通過(guò)BINLOG把丟失的部分?jǐn)?shù)據(jù)通過(guò)手工同步到從庫(kù)上去。

注意：主庫(kù)宕機(jī)的情況下，DBA可以通過(guò)mysqlbinlog工具手工訪問(wèn)主庫(kù)binlog，抽取缺失的日志并同步到從庫(kù)上去；也可以通過(guò)配置高可用MHA架構(gòu)來(lái)自動(dòng)抽取缺失的數(shù)據(jù)補(bǔ)全從庫(kù)，或者啟用Global Transaction Identifiers（GTID)來(lái)自動(dòng)抽取缺失binlog到從庫(kù)。

MySQL在BINLOG中記錄事務(wù)(或SQL語(yǔ)句),也就是說(shuō)對(duì)于支持事務(wù)的的引擎(例如InnoDB)來(lái)說(shuō)，每個(gè)事務(wù)提交時(shí)都需要寫B(tài)INLOG；對(duì)于不支持事務(wù)的引擎(例如MyISAM)來(lái)說(shuō)，每個(gè)SQL語(yǔ)句執(zhí)行完成時(shí)，都需要些BINLOG。為了保證Binlog的安全，MySQL引入sync_binlog參數(shù)來(lái)控制BINLOG刷新到磁盤的頻率。

show variables like 'sync_binlog';

在默認(rèn)情況下，sync_binlog=1，表示事務(wù)提交之前，MySQL都需要先把BINLOG刷新到磁盤，這樣的話，即使出現(xiàn)數(shù)據(jù)庫(kù)主機(jī)操作系統(tǒng)崩潰或者主機(jī)突然掉電的情況，系統(tǒng)最多損失prepared狀態(tài)的事務(wù)；設(shè)置sync_binlog=1，盡可能保證數(shù)據(jù)安全。
sync_binlog=0,表示MySQL不控制binlog的刷新，由文件系統(tǒng)自己控制文件緩存的刷新。
sync_binlog=N,如果N不等于0或者1，刷新方式同sync_binlog=1類似，只不過(guò)此時(shí)會(huì)延長(zhǎng)刷新頻率至N次binlog提交組之后。

以上是傳統(tǒng)的異步復(fù)制，在MySQL5.7的并行復(fù)制技術(shù)(也稱多線程復(fù)制)到來(lái)之前，為人詬病最多的還是效率問(wèn)題，slave延遲是一個(gè)頑疾，雖然之前已經(jīng)出現(xiàn)了schema級(jí)別的并行復(fù)制，但實(shí)際效果并不好。

多線程復(fù)制

在MySQL5.7中，帶來(lái)了全新的多線程復(fù)制技術(shù)，解決了當(dāng)master同一個(gè)schema下的數(shù)據(jù)發(fā)生了變更，從庫(kù)不能并發(fā)應(yīng)用的問(wèn)題，同時(shí)也真正將binlog組提交的優(yōu)勢(shì)充分發(fā)揮出來(lái)，保障了從庫(kù)并發(fā)應(yīng)用Relay Log的能力。

在MySQL8.0中，多線程復(fù)制又進(jìn)行了技術(shù)更新，引入了writeset的概念，而在之前的版本中，如果主庫(kù)的同一個(gè)會(huì)話順序執(zhí)行多個(gè)不同相關(guān)對(duì)象的事務(wù)，例如，先執(zhí)行了Update A表的數(shù)據(jù)，又執(zhí)行了Update B表的數(shù)據(jù)，那么BINLOG在復(fù)制到從庫(kù)后，這兩個(gè)事務(wù)是不能并行執(zhí)行的，writeset的到來(lái)，突破了這個(gè)限制。

增強(qiáng)半同步復(fù)制

前面介紹的復(fù)制是異步操作，主庫(kù)和從庫(kù)的數(shù)據(jù)之間難免會(huì)存在一定的延遲，這樣存在一個(gè)隱患：當(dāng)在主庫(kù)上寫入一個(gè)事務(wù)并提交成功，而從庫(kù)尚未得到主庫(kù)的BINLOG日志時(shí)，主庫(kù)由于磁盤損壞、內(nèi)存故障、斷電等原因意外宕機(jī)，導(dǎo)致主庫(kù)上該事務(wù)BINLOG丟失，此時(shí)從庫(kù)就會(huì)損失這個(gè)事務(wù)，從而造成主從不一致。

為了解決這個(gè)問(wèn)題，從MySQL5.5開(kāi)始，引入了半同步復(fù)制，此時(shí)的技術(shù)暫且稱之為傳統(tǒng)的半同步復(fù)制，因該技術(shù)發(fā)展到MySQL5.7后，已經(jīng)演變?yōu)樵鰪?qiáng)半同步復(fù)制(也成為無(wú)損復(fù)制)。在異步復(fù)制時(shí)，主庫(kù)執(zhí)行Commit提交操作并寫入BINLOG日志后即可成功返回客戶端，無(wú)需等待BINLOG日志傳送給從庫(kù)，如圖所示。

而半同步復(fù)制時(shí)，為了保證主庫(kù)上的每一個(gè)BINLOG事務(wù)都能夠被可靠地復(fù)制到從庫(kù)上，主庫(kù)在每次事務(wù)成功提交時(shí)，并不及時(shí)反饋給前端應(yīng)用用戶，而是等待至少一個(gè)從庫(kù)(詳見(jiàn)參數(shù)rpl_semi_sync_master_wait_for_slave_count)也接收到BINLOG事務(wù)并成功寫入中繼日志后，主庫(kù)才返回Commit操作成功給客戶端(不管是傳統(tǒng)的半同步復(fù)制，還是增強(qiáng)的半同步復(fù)制，目的都是一樣的，只不過(guò)兩種方式有一個(gè)席位地方不同，將在下面說(shuō)明)

半同步復(fù)制保證了事務(wù)成功提交后，至少有兩份日志記錄，一份在主庫(kù)的BINLOG日志上，另一份在至少一個(gè)從庫(kù)的中繼日志Relay Log上，從而更進(jìn)一步保證了數(shù)據(jù)的完整性。

在傳統(tǒng)的半同步復(fù)制中，主庫(kù)寫數(shù)據(jù)到BINLOG，且執(zhí)行Commit操作后，會(huì)一直等待從庫(kù)的ACK，即從庫(kù)寫入Relay Log后，并將數(shù)據(jù)落盤，返回給主庫(kù)消息，通知主庫(kù)可以返回前端應(yīng)用操作成功，這樣會(huì)出現(xiàn)一個(gè)問(wèn)題，就是實(shí)際上主庫(kù)已經(jīng)將該事務(wù)Commit到了事務(wù)引擎層，應(yīng)用已經(jīng)可以可以看到數(shù)據(jù)發(fā)生了變化，只是在等待返回而已，如果此時(shí)主庫(kù)宕機(jī)，有可能從庫(kù)還沒(méi)能寫入Relay Log，就會(huì)發(fā)生主從庫(kù)不一致。增強(qiáng)半同步復(fù)制就是為了解決這個(gè)問(wèn)題，做了微調(diào)，即主庫(kù)寫數(shù)據(jù)到BINLOG后，就開(kāi)始等待從庫(kù)的應(yīng)答ACK，直到至少一個(gè)從庫(kù)寫入Relay Log后，并將數(shù)據(jù)落盤，然后返回給主庫(kù)消息，通知主庫(kù)可以執(zhí)行Commit操作，然后主庫(kù)開(kāi)始提交到事務(wù)引擎層，應(yīng)用此時(shí)可以看到數(shù)據(jù)發(fā)生了變化。增強(qiáng)半同步復(fù)制的大致流程如下圖所示。

半同步復(fù)制模式下，假如在傳送BINLOG日志到從庫(kù)時(shí)，從庫(kù)宕機(jī)或者網(wǎng)絡(luò)延遲，導(dǎo)致BINLOG并沒(méi)有即使地傳送到從庫(kù)上，此時(shí)主庫(kù)上的事務(wù)會(huì)等待一段時(shí)間(時(shí)間長(zhǎng)短由參數(shù)rpl_semi_sync_master_timeout設(shè)置的毫秒數(shù)決定)，如果BINLOG在這段時(shí)間內(nèi)都無(wú)法成功發(fā)送到從庫(kù)上，則MySQL自動(dòng)調(diào)整復(fù)制為異步模式，事務(wù)正常返回提交結(jié)果給客戶端。

半同步復(fù)制很大程度上取決于主從庫(kù)之間的網(wǎng)絡(luò)情況，往返時(shí)延RTT越小決定了從庫(kù)的實(shí)時(shí)性越好。通俗地說(shuō)，主從庫(kù)之間的網(wǎng)絡(luò)越快，從庫(kù)約實(shí)時(shí)。

注意：往返時(shí)延RTT(Round-Trip Time)在計(jì)算機(jī)網(wǎng)絡(luò)中是一個(gè)重要的性能指標(biāo)，它表示從發(fā)送端發(fā)送數(shù)據(jù)開(kāi)始到發(fā)送端接收到接收端的確認(rèn)，總共經(jīng)歷的時(shí)長(zhǎng)(這里可能有點(diǎn)拗口，我們可以理解為TCP三次握手的前兩次握手)。

總結(jié)

到此這篇關(guān)于關(guān)于MySQL主從復(fù)制的文章就介紹到這了,更多相關(guān)MySQL主從復(fù)制方式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: