背景介紹
複製，就是對數據的完整拷貝，說到爲什麼要複製，首先能想到的是怕數據意外丟失，使得用戶蒙受損失。
當完成了數據複製之後，會發現它的優勢不止這一點，假如一臺機器宕機了，可以啓用備份在另一臺機器的數據。畢竟宕機的概率很小，閒暇時間還可以讓備份機器分擔主機器的流量壓力。除此之外，當要升級數據庫版本時，可以在不停止用戶服務的情況下優先升級備用機器，待觀測其可用穩定時再將主數據庫升級。
但是，也不能總讓DBA手動拷貝來完成複製，萬一在DBA蹲坑的時候宕機了，在蹲坑期間產生的數據由於沒有及時備份，會導致備用數據庫的數據缺失，所以還是要設計一套可以自動複製的機制。
設計複製機制
我們暫定被複制的數據庫爲主庫，粘貼出來的爲從庫，要實現主庫到從庫的複製，看起來非常簡單，只需一個計劃任務，定時將主庫數據文件複製一份，並傳輸到從庫所在服務器。
但畢竟定時任務不是實時的，萬一主庫在上次複製的十分鐘後發生了故障，被激活的從庫用的是最近一次複製的數據，所以會缺失十分鐘的數據，後果不堪設想。
還是要實時複製，那可以這樣，主庫將每次執行完的語句實時發給從庫，讓從庫馬上執行，就能保證兩邊數據一致了。
不太好的是，主庫是實時發送數據給從庫的，需要等從庫執行完畢才能處理下一條語句，嚴重佔用了主庫的執行時間，如果從庫過多，主庫就廢了。
還得改成異步才能節省主庫的時間，可以將主庫執行完的語句存到文件裏，讓從庫來取，這樣主庫就不用等待從庫了。既然是寫到文件，速度是很快的，主庫完全可以在執行前就將語句寫到文件中，達到更高的同步效率。
上述有些問題，從庫無法做到跑去主庫取數據，只能起一個線程先與主庫建立連接，並向主庫索要數據，然後主庫也起一個線程讀取文件內容，並推給從庫線程，從庫收到語句後就可以馬上執行了。
這樣效率還是很低，主庫的線程要等從庫收到語句並執行完畢才能推下一條，如果有多個從庫，主庫就要開啓多個線程長期與各個從庫保持通信，佔用主庫服務器資源，不如從庫也創建個文件臨時保存主庫發來的語句，先存起來再慢慢執行，主庫壓力小了，從庫也放心。
現在從庫有了自己的文件做中繼，就不用着急了，從庫可以再起一個線程，慢慢執行中繼文件中的語句，執行完畢之後原文件沒有價值了，就可以清理掉，免得佔用服務器資源。
到目前爲止，最基本的複製機制就設計完了，這種由主庫到從庫的複製方式就是典型的主從架構，在此基礎上可以進行演化，比如從庫有很多，主庫要爲每個從庫推送數據，主庫的壓力會隨之增大，又因爲主庫的職責不僅僅是同步數據，還要忙着讀寫數據，所以同步數據的事可以找人代替，比如在主庫與從庫之間再建立一個主庫，新建立的主庫唯一的職責就是同步數據給從庫，這樣真正的主庫就只需要推送一次數據給新建的主庫，其餘時間就可以安心讀寫數據了。
這種演化而來的複製模式叫做多級複製架構，本文到此結束，上述就是三種複製架構中的其中兩種，除此之外還有一個“主主”架構，在這裏就不再多說了，感興趣的可以自行了解或關注我們後續的文章。
如果你願意，讓我來幫你關注不知道又想知道卻想不到的知識。