異步複製
傳統的MySQL複製採用主從的方式進行，可以一主一從也可以一主多從主庫執行一個事務，提交後稍後異步的傳送到從庫中
如果是基於語句的複製則會重新執行，如果是基於行的負責則會應用日誌，同時是shared-nothing的架構，即所有服務器擁有同樣的數據複製。
傳統的MySQL主從複製架構是MySQL保持數據一致性的最基本架構，如下圖所示，一主一從架構，從庫給主庫發起讀數據請求後，主庫會通過 dump線程把binlog日誌文件推送給從庫，從庫的I/O線程把接收到數據更新到relay log，之後從庫的SQL線程把relay log應用爲binlog日誌，直到主庫與從庫的binlog日誌文件完全數據一致，達到主從同步 。
接下來我們看一下MySQL 異步複製，如下圖所示，一主兩從架構，應用發來的事務請求，經過執行之後寫入binlog，主庫master把binlog日誌推送給從庫 salve1和slave2 ，主庫不需要等到從庫是否成功更新數據到relay log，主庫直接提交事務即可。這種模式犧牲了數據一致性，不能很好保證主從數據一致性。
模擬異步複製場景舉例，如下圖所示，三個人對話，一個人在不停歇的演講，不需要知道兩個聽衆是否聽懂，聽衆也不需要做出迴應，等演講完畢，有可能聽衆沒聽懂，最終大家認知到信息可能不一致，爲了解決上述問題MySQL5.5.8 就有了半同步複製。
半同步複製
MySQL也提供了一個半同步複製，即同步複製，其要求主庫在commit時等待從庫接受 完事務並返回確認信息後才能提交
接下來看一下 MySQL的半同步複製，如下圖所示，一主兩從架構，應用發來的事務請求，在主庫執行後寫入binlog，主庫master把binlog日誌推送給從庫 salve1和slave2 ，半同步主庫需要等待其中任意一個從庫更新數據到relay log成功並且告知主庫，主庫才提交事務，這樣保證至少有一個從庫同步上數據了，也縮短了延遲時間，保證了數據安全。
模擬半同步複製場景舉例，如下圖所示，三個人對話，一個人在不停歇的演講，任意一個聽衆迴應聽懂了，演講者就繼續往下說，否則停止演講，最後等演講結束，至少一聽衆聽懂演講者的意思，保證信息傳遞一致性，這種複製模式也存在兩個問題：
1）MySQL無法自動切換，需要藉助外力切庫，運維複雜。
2）從庫Slave的讀壓力太大會導致複製延遲不斷增加。
MySQL5.7版本的MGR技術可以解決上述問題。至此MGR技術誕生！
組複製原理
- 組複製是一種可用於實現容錯系統的技術。 複製組是一個通過消息傳遞相互交互的 server 集羣。
- 通信層提供了原子消息(atomic message)和完全有序信息交互等保障機制。 這些是非常強大的功能,我們可以據此架構設計更高級的數據庫複製解決方案。
MySQL 組複製以這些功能和架構爲基礎,實現了基於複製協議的多主更新。
複製組由多個 server成員構成,並且組中的每個 server 成員可以獨立地執行事務。但所有讀寫(RW)事務只有在衝突檢測成功後纔會提交。只讀(RO)事務不需要在衝突檢測,可以立即提交。換句話說,對於任何 RW 事務,提交操作並不是由始發 server 單向決定的,而是由組來決定是否提交。準確地說,在始發 server 上,當事務準備好提交時,該 server 會廣播寫入值(已改變的行)和對應的寫入集(已更新的行的唯一標識符)。然後會爲該事務建立一個全局的順序。最終,這意味着所有 server 成員以相同的順序接收同一組事務。因此,所有 server 成員以相同的順序應用相同的更改,以確保組內一致。 - 在不同 server 上併發執行的事務可能存在衝突。 根據組複製的衝突檢測機制,對兩個不同的併發事務的寫集合進行檢測。如在不同的 server 成員執行兩個更新同一行的併發事務,則會出現衝突。排在最前面的事務可以在所有 server 成員上提交,第二個事務在源 server 上回滾,並在組中的其他 server 上刪除。 這就是分佈式的先提交當選規則。
-
單主模型和多主模型
-
MySQL組複製是MySQL 5.7.17開始引入的新功能，爲主從複製實現高可用功能。它支持單主模型和多主模型兩種工作方式(默認是單主模型)。
-
單主模型：從複製組中衆多個MySQL節點中自動選舉一個master節點，只有master節點可以寫，其他節點自動設置爲read only。當master節點故障時，會自動選舉一個新的master節點，選舉成功後，它將設置爲可寫，其他slave將指向這個新的master。
-
多主模型：複製組中的任何一個節點都可以寫，因此沒有master和slave的概念，只要突然故障的節點數量不太多，這個多主模型就能繼續可用。