mysql主從複制的常用拓撲結構

複制的體系結構有以下一些基本原則：

(1)    每個slave隻能有一個master；

(2)    每個slave隻能有一個唯一的伺服器ID；

(3)    每個master可以有很多slave；

(4)    如果你設定log_slave_updates，slave可以是其它slave的master，進而擴散master的更新。

MySQL不支援多主伺服器複制(Multimaster Replication)——即一個slave可以有多個master。但是，通過一些簡單的組合，我們卻可以建立靈活而強大的複制體系結構。

由一個master和一個slave組成複制系統是最簡單的情況。Slave之間并不互相通信，隻能與master進行通信。

在實際應用場景中，MySQL複制90%以上都是一個Master複制到一個或者多個Slave的架構模式，主要用于讀壓力比較大的應用的資料庫端廉價擴充解決方案。因為隻要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步複制的延時一般都很少很少。尤其是自從Slave端的複制方式改成兩個線程處理之後，更是減小了Slave端的延時問題。而帶來的效益是，對于資料實時性要求不是特别Critical的應用，隻需要通過廉價的pcserver來擴充Slave的數量，将讀壓力分散到多台Slave的機器上面，即可通過分散單台資料庫伺服器的讀壓力來解決資料庫端的讀性能瓶頸，畢竟在大多數資料庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的資料庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決資料庫瓶頸。

如下：

 如果寫操作較少，而讀操作很時，可以采取這種結構。你可以将讀操作分布到其它的slave，進而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網絡帶寬都會成為一個嚴重的問題。

這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：

(1)    不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；

(2)    用一個slave作為備用master，隻進行複制；

(3)    用一個遠端的slave，用于災難恢複；

大家應該都比較清楚，從一個Master節點可以複制出多個Slave節點，可能有人會想，那一個Slave節點是否可以從多個Master節點上面進行複制呢？至少在目前來看，MySQL是做不到的，以後是否會支援就不清楚了。

MySQL不支援一個Slave節點從多個Master節點來進行複制的架構，主要是為了避免沖突的問題，防止多個資料源之間的資料出現沖突，而造成最後資料的不一緻性。不過聽說已經有人開發了相關的patch，讓MySQL支援一個Slave節點從多個Master結點作為資料源來進行複制，這也正是MySQL開源的性質所帶來的好處。

Master-Master複制的兩台伺服器，既是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中，就更不用擔心可能會出現循環複制的情形了。

如圖：

主動的Master-Master複制有一些特殊的用處。例如，地理上分布的兩個部分都需要自己的可寫的資料副本。這種結構最大的問題就是更新沖突。假設一個表隻有一行(一列)的資料，其值為1，如果兩個伺服器分别同時執行如下語句：

在第一個伺服器上執行：

mysql> UPDATE tbl SET col=col + 1;

在第二個伺服器上執行：

mysql> UPDATE tbl SET col=col * 2;

那麼結果是多少呢？一台伺服器是4，另一個伺服器是3，但是，這并不會産生錯誤。

實際上，MySQL并不支援其它一些DBMS支援的多主伺服器複制(Multimaster Replication)，這是MySQL的複制功能很大的一個限制(多主伺服器的難點在于解決更新沖突)，但是，如果你實在有這種需求，你可以采用MySQL Cluster，以及将Cluster和Replication結合起來，可以建立強大的高性能的資料庫平台。但是，可以通過其它一些方式來模拟這種多主伺服器的複制。

這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在于其中一個服務隻能進行隻讀操作。如圖：

在有些應用場景中，可能讀寫壓力差别比較大，讀壓力特别的大，一個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也會更多，同樣可能造成延時較長的風險。

而如果我們通過分拆叢集的方式來解決的話，可能就會要好很多了，當然，分拆叢集也需要更複雜的技術和更複雜的應用系統架構。

這種結構的優點就是提供了備援。在地理上分布的複制結構，它不存在單一節點故障問題，而且還可以将讀密集型的請求放到slave上。

級聯複制在一定程度上面确實解決了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叢集可能出現的資料延時也會更為明顯，是以考慮使用多層級聯複制之前，也需要評估資料延時對應用系統的影響。

轉自：http://blog.csdn.net/hguisu/article/details/7325124