MySQL複製機制原理

背景介紹

複製，就是對數據的完整拷貝，說到爲何要複製，首先能想到的是怕數據意外丟失，使得用戶蒙受損失。

當完成了數據複製以後，會發現它的優點不止這一點，假如一臺機器宕機了，能夠啓用備份在另外一臺機器的數據。畢竟宕機的機率很小，閒暇時間還可讓備份機器分擔主機器的流量壓力。除此以外，當要升級數據庫版本時，能夠在不中止用戶服務的狀況下優先升級備用機器，待觀測其可用穩定時再將主數據庫升級。

可是，也不能總讓DBA手動拷貝來完成複製，萬一在DBA蹲坑的時候宕機了，在蹲坑期間產生的數據因爲沒有及時備份，會致使備用數據庫的數據缺失，因此仍是要設計一套能夠自動複製的機制。

設計複製機制

咱們暫定被複制的數據庫爲主庫，粘貼出來的爲從庫，要實現主庫到從庫的複製，看起來很是簡單，只需一個計劃任務，定時將主庫數據文件複製一份，並傳輸到從庫所在服務器。

但畢竟定時任務不是實時的，萬一主庫在上次複製的十分鐘後發生了故障，被激活的從庫用的是最近一次複製的數據，因此會缺失十分鐘的數據，後果不堪設想。

仍是要實時複製，那能夠這樣，主庫將每次執行完的語句實時發給從庫，讓從庫立刻執行，就能保證兩邊數據一致了。

不太好的是，主庫是實時發送數據給從庫的，須要等從庫執行完畢才能處理下一條語句，嚴重佔用了主庫的執行時間，若是從庫過多，主庫就廢了。

還得改爲異步才能節省主庫的時間，能夠將主庫執行完的語句存到文件裏，讓從庫來取，這樣主庫就不用等待從庫了。既然是寫到文件，速度是很快的，主庫徹底能夠在執行前就將語句寫到文件中，達到更高的同步效率。

上述有些問題，從庫沒法作到跑去主庫取數據，只能起一個線程先與主庫創建鏈接，並向主庫索要數據，而後主庫也起一個線程讀取文件內容，並推給從庫線程，從庫收到語句後就能夠立刻執行了。

這樣效率仍是很低，主庫的線程要等從庫收到語句並執行完畢才能推下一條，若是有多個從庫，主庫就要開啓多個線程長期與各個從庫保持通訊，佔用主庫服務器資源，不如從庫也建立個文件臨時保存主庫發來的語句，先存起來再慢慢執行，主庫壓力小了，從庫也放心。

如今從庫有了本身的文件作中繼，就不用着急了，從庫能夠再起一個線程，慢慢執行中繼文件中的語句，執行完畢以後原文件沒有價值了，就能夠清理掉，省得佔用服務器資源。

到目前爲止，最基本的複製機制就設計完了，這種由主庫到從庫的複製方式就是典型的主從架構，在此基礎上能夠進行演化，好比從庫有不少，主庫要爲每一個從庫推送數據，主庫的壓力會隨之增大，又由於主庫的職責不只僅是同步數據，還要忙着讀寫數據，因此同步數據的事能夠找人代替，好比在主庫與從庫之間再創建一個主庫，新創建的主庫惟一的職責就是同步數據給從庫，這樣真正的主庫就只須要推送一次數據給新建的主庫，其他時間就能夠安心讀寫數據了。

這種演化而來的複製模式叫作多級複製架構，本文到此結束，上述就是三種複製架構中的其中兩種，除此以外還有一個「主主」架構，在這裏就再也不多說了，感興趣的能夠自行了解或關注後續的文章。

歡迎關注公衆號【關愛程序員社區】，若是你願意，讓我來幫你關注你不知道又想知道卻想不到的知識。