溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

mysql中三種復(fù)制機(jī)制異步復(fù)制,半同步復(fù)制和并行復(fù)制詳細(xì)介紹

發(fā)布時(shí)間:2020-06-02 11:36:32 來源:網(wǎng)絡(luò) 閱讀:1199 作者:三月 欄目:MySQL數(shù)據(jù)庫(kù)

下面一起來了解下mysql中三種復(fù)制機(jī)制異步復(fù)制,半同步復(fù)制和并行復(fù)制,相信大家看完肯定會(huì)受益匪淺,文字在精不在多,希望mysql中三種復(fù)制機(jī)制異步復(fù)制,半同步復(fù)制和并行復(fù)制這篇短內(nèi)容是你想要的。

**# 異步復(fù)制

異步復(fù)制是MySQL自帶的最原始的復(fù)制方式,主庫(kù)和備庫(kù)成功建立復(fù)制關(guān)系后,在備庫(kù)上會(huì)有一個(gè)IO線程去主庫(kù)拉取binlog,并將binlogx到本地,就是下圖中Relaylog,然后備庫(kù)會(huì)開啟另外一個(gè)SQL線程取回放Relay  log,通過這種方式達(dá)到Master-Slave數(shù)據(jù)同步的目的。

通常情況下,slave是只讀的,可以承擔(dān)一部分讀流量,而且可以根據(jù)實(shí)際需要,添加一個(gè)或者多個(gè)slave,這樣在一定程度上可以緩解主庫(kù)的讀壓力;

    另一方面,若Master出現(xiàn)異常(crash,硬件故障等),無法對(duì)外提供服務(wù),此時(shí)Slave可以承擔(dān)起master的重任,避免了單點(diǎn)的產(chǎn)生,所以復(fù)制就是為容災(zāi)和提高性能而生。

**  半同步復(fù)制**
**1.概念**
一般情況下,異步復(fù)制就已經(jīng)足夠應(yīng)付了,但由于是異步復(fù)制,備庫(kù)極有可能是落后于主庫(kù),特別是極端情況下,我們無法保證主備數(shù)據(jù)是嚴(yán)格一致的(即使我們觀察到Seconds  Behind  Master這個(gè)值為0)

比如,當(dāng)用戶發(fā)起commit命令時(shí),Master并不關(guān)心slave的執(zhí)行狀態(tài),執(zhí)行成功后,立即返回給用戶。試想下,若一個(gè)事務(wù)提交后,master成功返回給用戶后crash,這個(gè)事務(wù)的binlog還沒來得及傳遞到slave,那么slave相對(duì)于master而言就少了一個(gè)事務(wù),此時(shí)主備就不一致了。對(duì)于要求強(qiáng)一致的業(yè)務(wù)是不可以接受的,半同步復(fù)制就是為了解決數(shù)據(jù)一致性而產(chǎn)生的。

為什么叫半同步復(fù)制?我們來先說說同步復(fù)制,所謂同步復(fù)制就是一個(gè)事務(wù)在master和slave都執(zhí)行后,才返回給用戶執(zhí)行成功。這里核心是說master和slave要么都執(zhí)行,要么都不執(zhí)行,涉及到2pc(2  phrase  commit)。而MySQL只實(shí)現(xiàn)了本地redo-log和binlog的2PC,但并沒有實(shí)現(xiàn)master和slave的2PC,所以不是嚴(yán)格意義上的同步復(fù)制。而MySQL半同步復(fù)制不要求slave執(zhí)行,而僅僅是接收到日志后,就通知master可以返回了。

  這里關(guān)鍵點(diǎn)是slave 接受日志后是否執(zhí)行,若執(zhí)行后才通知master則是同步復(fù)制,若僅僅是接受日志成功,則是半同步復(fù)制。

     半同步復(fù)制如何實(shí)現(xiàn)?半同步復(fù)制實(shí)現(xiàn)的關(guān)鍵點(diǎn)是master對(duì)于事務(wù)提交過程特殊處理。目前實(shí)現(xiàn)半同步復(fù)制主要是有兩種模式,AFTER_SYNC模式和AFER_COMMIT模式。兩種方式的主要區(qū)別在與是否在存儲(chǔ)引擎提交后等待slave的ACK.

     2、AFTER_COMMIT模式
           先來看看AFTER_COMMIT模式,start和End分別表示用戶發(fā)起commit命令和master返回給用戶的時(shí)間點(diǎn),中間部分就是整個(gè)commit過程master和slave做的事情。

                 master提交時(shí),會(huì)首先將該事務(wù)的redo  log刷入磁盤(這里其實(shí)還涉及到兩階段提交的問題),然后進(jìn)入Inodb  commit過程,這個(gè)步驟主要是釋放鎖,標(biāo)記事務(wù)為提交狀態(tài)(其他用戶可以看到該事務(wù)的更新),這個(gè)過程完成后,等待slave發(fā)送ack消息,等到slave的響應(yīng)后,master才成功返回給用戶,master和slave的同步邏輯,是master-slave一致性的保證。

        3、AFTER_SYNC模式
        與AFTER_COMMIT相比,Master在AFTER_SYNC模式下,fsync  binlog后,就開始等待slave同步,那么在進(jìn)行第5步innodbcommit后,即其他事務(wù)能看到該事務(wù)的更新時(shí),slave已經(jīng)成功接收到binlog,即使發(fā)生切換,slave擁有與master同樣的數(shù)據(jù),不會(huì)發(fā)生“幻讀”現(xiàn)象。但是對(duì)于上面描述的第一種情況,結(jié)果是一樣的。

        所以,在極端情況下,半同步復(fù)制的master-slave會(huì)有一個(gè)事務(wù)不一致,但是對(duì)于用戶而言,由于這個(gè)事務(wù)并沒有成功返回給用戶,所以無論事務(wù)提交與否都是可以接受的,用戶有必要進(jìn)行查詢或重試,判讀是否更新成功?;蛘呶覀兿胂?,對(duì)于單機(jī)而言,若事務(wù)執(zhí)行成功后,返回給用戶時(shí),網(wǎng)絡(luò)斷了,用戶也是面臨一樣的問題,所以,這不是半同步復(fù)制的問題,對(duì)于提交返回成功的事務(wù),半同步復(fù)制保證master-slave一定是一致的,從這個(gè)角度來看,半同步復(fù)制不會(huì)丟數(shù)據(jù),可以保證master-slave的強(qiáng)制性。

并行復(fù)制
半同步復(fù)制解決了Master-slave 強(qiáng)一致問題,那么性能問題呢?參與復(fù)制的兩個(gè)線程:IO線程和SQL線程,分別用于拉取和回放binlog。對(duì)于slave而言,所有拉取和解析binlog的動(dòng)作都是串行的,相對(duì)與master并發(fā)處理用戶請(qǐng)求,在高負(fù)載下,若master產(chǎn)生binlog的速度超過slave消費(fèi)binlog的速度,導(dǎo)致slave出現(xiàn)延遲,可以看到,users和master之間的管道遠(yuǎn)遠(yuǎn)大于master和salve之間的管道。

 那么如何并行化,并行io線程,還是并行sql線程?其實(shí)兩方面都可以并行,但是并行sql線程的收益更大,因?yàn)閟ql線程做的事情更多(解析,執(zhí)行)。并行IO線程,可以將從master拉取和寫入relay  log分為兩個(gè)線程;并行sql線程則可以根據(jù)需要做到庫(kù)級(jí)并行,表級(jí)并行,事務(wù)級(jí)并行。庫(kù)級(jí)并行在MySQL官方版本5.6已經(jīng)實(shí)現(xiàn)了。并行復(fù)制框架實(shí)際包含了一個(gè)協(xié)調(diào)線程和若干個(gè)工作線程。協(xié)調(diào)線程負(fù)責(zé)分發(fā)和解決沖突,工作線程只負(fù)責(zé)執(zhí)行。

 DB1,DB2和DB3的事務(wù) 就可以并發(fā)執(zhí)行,提高了復(fù)制的性能。有時(shí)候庫(kù)級(jí)并發(fā)可能不夠,需要做表級(jí)并發(fā),或更細(xì)粒的事務(wù)級(jí)并發(fā)。

 **并行復(fù)制如何處理沖突?**
   并發(fā)的世界是美好的,但不能亂并發(fā),否則數(shù)據(jù)就亂了。master上面通過鎖機(jī)制來保證并發(fā)的事務(wù)有序進(jìn)行,那么并行復(fù)制呢?slave必需保證回放的順序與master上事務(wù)執(zhí)行順序一致,因此只要做到順序讀取binlog,將不沖突的事務(wù)并發(fā)執(zhí)行即可。對(duì)于庫(kù)級(jí)并發(fā)而言,協(xié)調(diào)線程要保證執(zhí)行同一個(gè)庫(kù)的事務(wù)放在一個(gè)工作線程串行執(zhí)行;對(duì)于表級(jí)并發(fā)而言,協(xié)調(diào)線程要保證同一個(gè)表的事務(wù)串行執(zhí)行;對(duì)于事務(wù)級(jí)而言,則是保證操作同一行的事務(wù)串行執(zhí)行。

     **是否粒度越細(xì),性能越好?**

      這個(gè)并不是一定的。相對(duì)與串行復(fù)制而言,并行復(fù)制多了一個(gè)協(xié)調(diào)線程。協(xié)調(diào)線程一個(gè)重要作用是解決沖突,粒度越細(xì)的并發(fā),可能會(huì)有更多的沖突,最終可能也是串行執(zhí)行的,但消耗了 大量的沖突檢測(cè)代價(jià)。

看完mysql中三種復(fù)制機(jī)制異步復(fù)制,半同步復(fù)制和并行復(fù)制這篇文章后,很多讀者朋友肯定會(huì)想要了解更多的相關(guān)內(nèi)容,如需獲取更多的行業(yè)信息,可以關(guān)注我們的行業(yè)資訊欄目。

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI