1.簡介
本文提供mysql組複製的背景信息。
創建一個容錯系統的最常見的方法是求助於組件冗餘，換句話說，組件能被移除，但系統將如期可以繼續操作。這將整個系統的複雜度提升到了更具挑戰性的級別。尤其是，複製庫必須面對多個而非一個服務器維護和管理的問題。然而，這些服務器一起合作形成一個組，但必須面對幾個其他經典分佈式系統問題，像網絡分區和腦裂等場景。
所以，最終的挑戰是將數據庫和數據複製邏輯與幾臺協作的服務器邏輯按照一致簡單的方式融合到一起。換句話說，就是讓多個服務器的系統狀態，數據和系統經歷的每個改變都達成一致。總之，就是讓多個服務器上的數據庫狀態轉換達成一致，以便所有服務器作爲一個數據庫一起運行，或最終多個服務器能達成同一狀態。這意味着，多個服務器需要作爲一個（分佈式）狀態機器進行操作。
mysql組複製通過服務器間的強大協調功能提供分佈式狀態機器複製。當多個服務器成爲同一組的部分時，它們自動相互協調。該組可以自動主機選舉的單一主機模式運行，其中，任意時刻只有一個服務器可以修改。
另外，對更高級的用戶，該組還可以多主機模式部署，其中，所有的服務器都可以進行修改，即使它們同時發佈。該模式以應用避免其限制作爲代價。
有一個內建的組成員服務，其可以在任何時間點爲所有服務器保持組一致性和可用性的視圖。服務器能離開和加入組，同時，該視圖也會相應更新。有時服務器也會意外離開組，此時，失敗探測機制探測到這種情況，並通知組視圖已發生改變。所有這一切都是自動進行的。對一個事務的提交，組內大部分成員必須同意事務全局順序中事務的順序。每個服務器單獨決定提交或終止一個事務，但所有服務器需要做出同樣的決定。
如果有網絡分區，導致組內成員不能達成一致，那麼，直到該問題得以解決，系統纔會繼續進行。然而，也有一個內建的、自動的腦裂保護機制。
所有這些都通過組通信系統（Group Communication System,GCS）協議進行驅動。這提供了一個失敗探測機制，一個組成員服務，和安全完全排序的消息交付。所有這些對創建一個確保數據在服務器組內進行一致複製的系統非常關鍵。該技術的核心在於實施Paxos算法。其扮演組通信引擎的角色。
2.複製技術
介紹mysql組複製（MGR）細節前，該部分先介紹一些背景概念和工作機制的概覽。這有助於理解組複製需要什麼，以及經典異步mysql複製和組複製間差別。
1）主從複製（primary-secondary replication）
傳統mysql複製提供了一種簡單的主從複製方法。其中，有一個主庫和一個或多個從庫。主庫執行事務並進行提交，然後，這些事務被送到（一般爲異步）從庫被重新執行（基於語句的複製）或應用（基於行的複製）。
該架構爲無共享（share-nothing）的系統，其中，所有服務器默認都有一份完整的數據拷貝。
也有一種半同步複製，其中，在協議中增加了一個同步步驟。這意味着，提交時主庫等待從庫已經收到事務的回執。此時，主庫纔會繼續事務的提交操作。
2）組複製
組複製爲一種實施容錯系統的技術。複製組爲一套通過信息傳遞相互作用的服務器。通信層提供一套類似原子信息和整體有序信息傳遞的保障機制。這些強有力的屬性能被轉換成很有用的抽象層，通過它可以構建更高級的數據庫複製解決方案。
mysql組複製建立在這些屬性和抽閒層之上，並實施了多主庫任意地點更新複製協議。實際上，一個複製組由多個服務器組成，且組內的每個服務器可以獨立的執行事務。但所有的讀寫（RW）事務僅被該組同意後才能被提交。只讀事務無需組內進行協調就可以立即提交。換句話說，任何讀寫事務，該組都得決定是否提交，因此，提交操作並非源服務器的一個單邊決定。更精確的講，當事務在源服務器上準備提交時，該服務器自動將寫值（rows changed，改變行）和通信寫集合（被修改行的唯一鑑定符）進行廣播。接着，爲該事務建立一個全局總順序。最後，這意味着所有服務器按照同樣的順序收到同樣一套事務。作爲結果，所有服務器按照同行順序應用同樣一套改變，所以，它們在組內保持能保持一致。
然而，不同服務器上同時執行的事務間也許會有衝突。通過對兩個不同和併發事務的寫集合進行檢查可以探測到這種衝突，這個過程稱爲認證。如果兩個在不同服務器上執行的併發事務，更改同樣的數據行，這將會發生衝突。解決過程爲排在第一位的事務將在所有服務器上進行提交，而排在第二位的事務將被終止，這將導致該事務在源服務器上進行回滾，並在組內其他服務器上對該事務進行刪除。這實際上是一個先提交先贏的分佈式規則。
最後，組複製是一個無共享的複製方案，其中，每個服務器都有其自己的一份完整的數據拷貝。
3.組複製使用場景
組複製通過將系統狀態複製到一套服務器的冗餘技術來創建容錯系統。因此，即使某些服務器失敗了，只要大部分服務器沒失敗，系統就還是可用的，最多就是導致性能和可伸縮性的降級，但還是可用的。失敗的服務器被隔離和獨立出來。這些服務器被一組依賴於分佈式失敗探測器的服務進行跟蹤，當任何服務器由於資源或意外終止而離開組時，這些分佈式失敗探測器可以發送信號。一個分佈式恢復過程確保當服務器加入組時其狀態會被自動更新。不必進行服務器失敗切換，多主隨地更新的特性確保單個服務器失敗事件中不會阻塞任何更新。索引mysql組複製保證數據庫服務是連續可用的。
理解一點很重要，那就是當服務器崩潰時，連接到該服務器的客戶端必須重定向，或失敗切換到其他不同的服務器。這並非mysql組複製試圖解決的問題。連接器，負載均衡器，路由器或某些中間件更適合處理這些問題。
總之，mysql組複製提供一個高可用的，高彈性的，可靠的mysql服務。
1）案例場景實例
下面是使用組複製的典型使用案例。
--彈性複製：需要頻繁變化複製架構的環境，其中，服務器的數量必須動態的增長或收縮，且儘量降低其帶來的副作用。例如：雲數據庫服務。
--高可用分片：分片是一種獲取寫擴展的流行方法。通過mysql組複製實施高可用分片，其中，每個分片映射到複製組。
--master-slave複製的替代方案：某些環境中，使用單主服務器會導致單一衝突點。對整個組的寫操作在某些環境下也許會提供更好的伸縮性。
--自主系統：另外，可以利用mysql組複製內建於複製協議的自動機來實現這種自主系統。
4.組複製細節
該部分提供組複製基於的某些服務的具體細節。
1）失敗探測
有一個失敗探測機制，該機制能發現和報告那個服務器沒反應，並假設該服務器已經死機。高層面上，失敗探測機制是一個能提供有關哪些服務器也許死機（存疑）信息的分佈式服務。稍後如果組認爲存疑的服務器可能是真的死機，那麼，該組決定該服務器確實已經失敗了。這意味着組內剩餘成員共同決定將該已失敗的成員排除在外。
當服務器沒反應時就會觸發存疑。在特定期間內服務器A收不到服務器B的信息，將發生超時和產生存疑。
如果一個服務器被從組內其餘成員隔離，那麼，其將認爲所有其他服務器已經失敗。不能與組達成協議（由於它達不到法定人數），因此，它的存疑並不會有結果。當一個服務器以這種方式被從組隔離時，它並不能執行任何本地事務。
2）組成員
mysql組複製依賴於一個組成員服務。這被建立在插件內。其定義哪些服務器在線並參與組。在線服務器其列表通常被作爲一個視圖參考。所以，任意時刻組內的每個服務器都會有一個關於哪些服務器參與組的一致性視圖。
服務器不僅同意事物提交，還同意哪個是當前視圖。所以，如果服務器同意一個新服務器加入組，那麼，組將被重新配置以將該服務器集成進來，從而觸發一個視圖的改變。相反，如果一個服務器離開組，無論是否自願，那麼，組將動態重新安排配置並觸發視圖修改。
一個成員自願離開時，將首先初始化一個動態組重配置。這將觸發一個過程，期間，所有成員必須同意沒有該離開服務器的新視圖。然而，如果一個成員不自願的離開（例如：意外停止或網絡不通），那麼，失敗探測機制認識到這個事實，並提議組內大多數服務器進行重新配置，重配置後的組並不包含失敗的成員。如前述這將要求組內大多數服務器的同意。如果組不能達成一致（例如：其按照沒有大多數服務器在線的方式分區），那麼，系統不能動態改變配置，從而阻塞以阻止發生腦裂的情況。最終，這將意味着管理員需要接入和修復這種情況。
3）容錯
mysql組複製建立在Paxos分佈式算法的實施之上，從而支持服務器間的分佈式協調。這樣，其需要大多數服務器爲活動狀態以達到法定人數，並作出決定。這將直接影響系統能容忍的失敗服務器數，而不會對其本身和整體功能造成影響。需要容忍f個服務器失敗的服務器數（n）爲n = 2 x f + 1。
實際上，這意味着爲了容忍組的一個服務器失敗，組內必須有三個服務器。這樣如果一個服務器失敗了，還有兩個服務器形成大多數（三分之二），以允許系統繼續自動做出決定並前進。然而，如果第二個服務器意外失敗了，那麼組（只剩下一個服務器）發生阻塞，因爲沒有大多數來做出決定。