（一）複製技術的發展
MySQL的複製技術主要經歷了非同步主從複製，半同步複製，組複製(Group Replication)3個階段。
（1）傳統的非同步主從複製
傳統的MySQL提供了一種簡單的主從複製方法。有1個主伺服器(master)，有1個或多個從伺服器(slave)，主伺服器執行事務，然後提交，從伺服器非同步接收日誌，並重新應用日誌。
該架構存在的問題有：如果主伺服器/資料庫crash了，日誌沒有完成傳送到備庫，那麼當備庫切換為主庫的時候，可能存在資料丟失的風險。
非同步複製架構如下：
圖1.MySQL Asynchronous Replication
（2）半同步複製
半同步複製向同步協議新增一個步驟，這意味著主庫在執行提交的時候，需要等待從庫確認已經接收到事務，才能進行提交。
該架構存在的問題有：主庫必須等待備庫接收到日誌並返回響應才算完成事物，造成了主庫的延遲，這個延遲最少是一個TCP/IP往返的時間，因此半同步複製最好在延遲低的網路中使用
半同步複製架構如下：
圖2.MySQL semisynchronous Replication
（3）組複製
組複製是一種可用於實施容錯系統的技術。組複製是一組伺服器，每個伺服器都有自己的完整資料副本，並通過訊息傳遞相互互動。一個組複製由多個伺服器組成，該組中的每個伺服器都可以隨時獨立執行事務。但是，所有讀寫事務僅在獲得組批准後才提交，換句話說，對於任何讀寫事務，該組都需要確定提交，因此提交操作不是來自原始伺服器的單方面決定。只讀事務不需要組內協調，可以立即提交。
組複製可以是單主模式和多主模式，多主模式意味所有組成員都可以執行寫操作，這樣就可能存在事務衝突，根據組複製衝突監測機制，如果存在兩個不同的server成員更新同一行的併發事務，排在最前面的可以在所有server成員上提交，第二個事務在源server上回滾，並在組中的其它server上刪除。
圖3.MySQL Group Replication
關於三種複製技術，個人覺得：非同步複製提供了主從方案，降低了單節點執行資料庫的風險；後續的半同步複製是非同步主從複製的加強，解決了資料丟失的風險，但是依然存在網路延遲，切換麻煩的問題(例如10個節點，1主9從，主節點當機，當把一個從節點提升為主節點後，其它節點需要手動修改master)，而組複製則擁有了自動故障轉移failover的能力，當主節點發生故障(單主模式才需考慮)時，組內部會自動選擇主節點。
組複製建立在Paxos分散式演算法之上，以提供伺服器之間的分散式協調，因此，他需要大多數伺服器處於活動狀態才能正常工作。如果有n臺伺服器，最多允許故障的伺服器數量為f，那麼n與f之間的關係為：n=2f+1。或許這麼看有些難以理解，可以看下面的關係：
| 組複製伺服器數量 | 多數 | 允許故障的伺服器數量 |
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
對組複製有了一定的瞭解，接下來，我們一起來搭建組複製。。。