MySQLReplicaion的經常使用架構

常規復制架構　 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性能調優與架構》