前言
MySQLReplicaion本身是一個比較簡單的架構，就是一台MySQL服務器（Slave）從另一台MySQL服務器（Master）進行日志的復制然后再解析日志並應用到自身。一個復制環境僅僅只需要兩台運行有MySQLServer的主機即可，甚至更為簡單的時候我們可以在同一台物理服務器主機上面啟動兩個mysqldinstance，一個作為Master而另一個作為Slave來完成復制環境的搭建。但是在實際應用環境中，我們可以根據實際的業務需求利用MySQLReplication的功能自己定制搭建出其他多種更利於ScaleOut的復制架構。如DualMaster架構，級聯復制架構等。下面我們針對比較典型的三種復制架構進行一些相應的分析介紹。
常規復制架構 Master - Slaves
在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之后，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多台Slave的機器上面，即可通過分散單台數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
這個架構可以通過下圖比較清晰的展示：
一個Master復制多個Slave的架構實施非常簡單，多個Slave和單個Slave的實施並沒有實質性的區別。在Master端並不Care有多少個Slave連上了自己，只要有Slave的IO線程通過了連接認證，向他請求指定位置之后的BinaryLog信息，他就會按照該IO線程的要求，讀取自己的BinaryLog信息，返回給Slave的IO線程。
大家應該都比較清楚，從一個Master節點可以復制出多個Slave節點，可能有人會想，那一個Slave節點是否可以從多個Master節點上面進行復制呢？至少在目前來看，MySQL是做不到的，以后是否會支持就不清楚了。
MySQL不支持一個Slave節點從多個Master節點來進行復制的架構，主要是為了避免沖突的問題，防止多個數據源之間的數據出現沖突，而造成最后數據的不一致性。不過聽說已經有人開發了相關的patch，讓MySQL支持一個Slave節點從多個Master結點作為數據源來進行復制，這也正是MySQL開源的性質所帶來的好處。
對於Replication的配置細節，在MySQL的官方文檔上面已經說的非常清楚了，甚至介紹了多種實現Slave的配置方式，在下一節中我們也會通過一個具體的示例來演示搭建一個Replication環境的詳細過程以及注意事項。
dualMaster復制架構 Master - Master
有些時候，簡單的從一個MySQL復制到另外一個MySQL的基本Replication架構，可能還會需要在一些特定的場景下進行Master的切換。如在Master端需要進行一些特別的維護操作的時候，可能需要停MySQL的服務。這時候，為了盡可能減少應用系統寫服務的停機時間，最佳的做法就是將我們的Slave節點切換成Master來提供寫入的服務。
但是這樣一來，我們原來Master節點的數據就會和實際的數據不一致了。當原Master啟動可以正常提供服務的時候，由於數據的不一致，我們就不得不通過反轉原Master-Slave關系，重新搭建Replication環境，並以原Master作為Slave來對外提供讀的服務。重新搭建Replication環境會給我們帶來很多額外的工作量，如果沒有合適的備份，可能還會讓Replication的搭建過程非常麻煩。
為了解決這個問題，我們可以通過搭建DualMaster環境來避免很多的問題。何謂DualMaster環境？實際上就是兩個MySQLServer互相將對方作為自己的Master，自己作為對方的Slave來進行復制。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
可能有些讀者朋友會有一個擔心，這樣搭建復制環境之后，難道不會造成兩台MySQL之間的循環復制么？實際上MySQL自己早就想到了這一點，所以在MySQL的BinaryLog中記錄了當前MySQL的server-id，而且這個參數也是我們搭建MySQLReplication的時候必須明確指定，而且Master和Slave的server-id參數值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判斷某個變更是從哪一個MySQLServer最初產生的，所以就很容易避免出現循環復制的情況。而且，如果我們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄復制過程中的變更到BinaryLog中，就更不用擔心可能會出現循環復制的情形了。
下如將更清晰的展示DualMaster復制架構組成：
通過DualMaster復制架構，我們不僅能夠避免因為正常的常規維護操作需要的停機所帶來的重新搭建Replication環境的操作，因為我們任何一端都記錄了自己當前復制到對方的什么位置了，當系統起來之后，就會自動開始從之前的位置重新開始復制，而不需要人為去進行任何干預，大大節省了維護成本。
不僅僅如此，DualMaster復制架構和一些第三方的HA管理軟件結合，還可以在我們當前正在使用的Master出現異常無法提供服務之后，非常迅速的自動切換另外一端來提供相應的服務，減少異常情況下帶來的停機時間，並且完全不需要人工干預。
當然，我們搭建成一個DualMaster環境，並不是為了讓兩端都提供寫的服務。在正常情況下，我們都只會將其中一端開啟寫服務，另外一端僅僅只是提供讀服務，或者完全不提供任何服務，僅僅只是作為一個備用的機器存在。為什么我們一般都只開啟其中的一端來提供寫服務呢？主要還是為了避免數據的沖突，防止造成數據的不一致性。因為即使在兩邊執行的修改有先后順序，但由於Replication是異步的實現機制，同樣會導致即使晚做的修改也可能會被早做的修改所覆蓋，就像如下情形：
時間點MySQL A MySQL B
1 更新x表y記錄為10
2 更新x表y記錄為20
3獲取到A日志並應用，更新x表的y記錄為10（不符合期望）
4獲取B日志更新x表y記錄為20（符合期望）
這中情形下，不僅在B庫上面的數據不是用戶所期望的結果，A和B兩邊的數據也出現了不一致。
當然，我們也可以通過特殊的約定，讓某些表的寫操作全部在一端，而另外一些表的寫操作全部在另外一端，保證兩端不會操作相同的表，這樣就能避免上面問題的發生了。
級聯復制架構 Master –Slaves - Slaves
在有些應用場景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個Master可能需要上10台甚至更多的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了，因為僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端因為復制就會消耗較多的資源，很容易造成復制的延時。
遇到這種情況如何解決呢？這時候我們就可以利用MySQL可以在Slave端記錄復制所產生變更的BinaryLog信息的功能，也就是打開—log-slave-update選項。然后，通過二級（或者是更多級別）復制來減少Master端因為復制所帶來的壓力。也就是說，我們首先通過少數幾台MySQL從Master來進行復制，這幾台機器我們姑且稱之為第一級Slave集群，然后其他的Slave再從第一級Slave集群來進行復制。從第一級Slave進行復制的Slave，我稱之為第二級Slave集群。如果有需要，我們可以繼續往下增加更多層次的復制。這樣，我們很容易就控制了每一台MySQL上面所附屬Slave的數量。這種架構我稱之為Master-Slaves-Slaves架構
這種多層級聯復制的架構，很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。下圖展示了多層級聯復制的Replication架構。
當然，如果條件允許，我更傾向於建議大家通過拆分成多個Replication集群來解決
上述瓶頸問題。畢竟Slave並沒有減少寫的量，所有Slave實際上仍然還是應用了所有的數據變更操作，沒有減少任何寫IO。相反，Slave越多，整個集群的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多台機器上面，所以不是很容易表現出來。
此外，增加復制的級聯層次，同一個變更傳到最底層的Slave所需要經過的MySQL也會更多，同樣可能造成延時較長的風險。
而如果我們通過分拆集群的方式來解決的話，可能就會要好很多了，當然，分拆集群也需要更復雜的技術和更復雜的應用系統架構。
dualMaster與級聯復制結合架構(Master-Master-Slaves)
級聯復制在一定程度上面確實解決了Master因為所附屬的Slave過多而成為瓶頸的問題，但是他並不能解決人工維護和出現異常需要切換后可能存在重新搭建Replication的問題。這樣就很自然的引申出了DualMaster與級聯復制結合的Replication架構，我稱之為Master-Master-Slaves架構
和Master-Slaves-Slaves架構相比，區別僅僅只是將第一級Slave集群換成了一台單獨的Master，作為備用Master，然后再從這個備用的Master進行復制到一個Slave集群。下面的圖片更清晰的展示了這個架構的組成：
這種DualMaster與級聯復制結合的架構，最大的好處就是既可以避免主Master的寫入操作不會受到Slave集群的復制所帶來的影響，同時主Master需要切換的時候也基本上不會出現重搭Replication的情況。但是，這個架構也有一個弊端，那就是備用的Master有可能成為瓶頸，因為如果后面的Slave集群比較大的話，備用Master可能會因為過多的SlaveIO線程請求而成為瓶頸。當然，該備用Master不提供任何的讀服務的時候，瓶頸出現的可能性並不是特別高，如果出現瓶頸，也可以在備用Master后面再次進行級聯復制，架設多層Slave集群。當然，級聯復制的級別越多，Slave集群可能出現的數據延時也會更為明顯，所以考慮使用多層級聯復制之前，也需要評估數據延時對應用系統的影響。
轉自 《MySQL性能調優與架構》