背景介紹

復(fù)制，就是對數(shù)據(jù)的完整拷貝，說到為什么要復(fù)制，首先能想到的是怕數(shù)據(jù)意外丟失，使得用戶蒙受損失。

當(dāng)完成了數(shù)據(jù)復(fù)制之后，會發(fā)現(xiàn)它的優(yōu)勢不止這一點，假如一臺機器宕機了，可以啟用備份在另一臺機器的數(shù)據(jù)。畢竟宕機的概率很小，閑暇時間還可以讓備份機器分擔(dān)主機器的流量壓力。除此之外，當(dāng)要升級數(shù)據(jù)庫版本時，可以在不停止用戶服務(wù)的情況下優(yōu)先升級備用機器，待觀測其可用穩(wěn)定時再將主數(shù)據(jù)庫升級。

但是，也不能總讓DBA手動拷貝來完成復(fù)制，萬一在DBA蹲坑的時候宕機了，在蹲坑期間產(chǎn)生的數(shù)據(jù)由于沒有及時備份，會導(dǎo)致備用數(shù)據(jù)庫的數(shù)據(jù)缺失，所以還是要設(shè)計一套可以自動復(fù)制的機制。

設(shè)計復(fù)制機制

我們暫定被復(fù)制的數(shù)據(jù)庫為主庫，粘貼出來的為從庫，要實現(xiàn)主庫到從庫的復(fù)制，看起來非常簡單，只需一個計劃任務(wù)，定時將主庫數(shù)據(jù)文件復(fù)制一份，并傳輸?shù)綇膸焖诜?wù)器。

但畢竟定時任務(wù)不是實時的，萬一主庫在上次復(fù)制的十分鐘后發(fā)生了故障，被激活的從庫用的是最近一次復(fù)制的數(shù)據(jù)，所以會缺失十分鐘的數(shù)據(jù)，后果不堪設(shè)想。

還是要實時復(fù)制，那可以這樣，主庫將每次執(zhí)行完的語句實時發(fā)給從庫，讓從庫馬上執(zhí)行，就能保證兩邊數(shù)據(jù)一致了。

不太好的是，主庫是實時發(fā)送數(shù)據(jù)給從庫的，需要等從庫執(zhí)行完畢才能處理下一條語句，嚴(yán)重占用了主庫的執(zhí)行時間，如果從庫過多，主庫就廢了。

還得改成異步才能節(jié)省主庫的時間，可以將主庫執(zhí)行完的語句存到文件里，讓從庫來取，這樣主庫就不用等待從庫了。既然是寫到文件，速度是很快的，主庫完全可以在執(zhí)行前就將語句寫到文件中，達(dá)到更高的同步效率。

上述有些問題，從庫無法做到跑去主庫取數(shù)據(jù)，只能起一個線程先與主庫建立連接，并向主庫索要數(shù)據(jù)，然后主庫也起一個線程讀取文件內(nèi)容，并推給從庫線程，從庫收到語句后就可以馬上執(zhí)行了。

這樣效率還是很低，主庫的線程要等從庫收到語句并執(zhí)行完畢才能推下一條，如果有多個從庫，主庫就要開啟多個線程長期與各個從庫保持通信，占用主庫服務(wù)器資源，不如從庫也創(chuàng)建個文件臨時保存主庫發(fā)來的語句，先存起來再慢慢執(zhí)行，主庫壓力小了，從庫也放心。

現(xiàn)在從庫有了自己的文件做中繼，就不用著急了，從庫可以再起一個線程，慢慢執(zhí)行中繼文件中的語句，執(zhí)行完畢之后原文件沒有價值了，就可以清理掉，免得占用服務(wù)器資源。

到目前為止，最基本的復(fù)制機制就設(shè)計完了，這種由主庫到從庫的復(fù)制方式就是典型的主從架構(gòu)，在此基礎(chǔ)上可以進(jìn)行演化，比如從庫有很多，主庫要為每個從庫推送數(shù)據(jù)，主庫的壓力會隨之增大，又因為主庫的職責(zé)不僅僅是同步數(shù)據(jù)，還要忙著讀寫數(shù)據(jù)，所以同步數(shù)據(jù)的事可以找人代替，比如在主庫與從庫之間再建立一個主庫，新建立的主庫唯一的職責(zé)就是同步數(shù)據(jù)給從庫，這樣真正的主庫就只需要推送一次數(shù)據(jù)給新建的主庫，其余時間就可以安心讀寫數(shù)據(jù)了。

這種演化而來的復(fù)制模式叫做多級復(fù)制架構(gòu)，本文到此結(jié)束，上述就是三種復(fù)制架構(gòu)中的其中兩種，除此之外還有一個“主主”架構(gòu)，在這里就不再多說了，感興趣的可以自行了解或關(guān)注后續(xù)的文章。

以上就是全部關(guān)于MySQL復(fù)制機制的知識點內(nèi)容，感謝大家對腳本之家的支持。

最新評論