MySQL有很多種復制，至少從概念上來看，傳統的主從復制，半同步復制，GTID復制，多線程復制，以及組復制（MGR）。
咋一看起來很多，各種各樣的復制，其實從原理上看，各種復制的原理並無太大的異同，新的復制方式的出現，是原復制某一方面增強或者是優化的結果，就不難理解為什麽有這麽多中復制。
每一種復制的出現都是有其原因的，也是解決（或者說是彌補）前一種的復制方案的潛在的問題的。
其實搞出來這麽多概念，個人覺得是源於開源的原因吧，不同復制版本的出現，因為是一個不斷發現問題就解決問題的過程。
如果是閉源的數據庫，你只管打補丁就行了，應該不會出現這麽多概念。

本文僅從原理上粗略總結各種復制技術的特點以及解決的問題，不涉及太多的細節問題。

大致的流程如下：

1，搭建完主從之後，slave連接至master，slave的io_thread等待主庫的binlog信息
2，master上執行各種DDL或者DML命令，執行完成執行生成binlog
3，master上的binlog_dump線程將生成的binlog傳送給slave的slave的io_thread
4，slave的io_thread接受到master上的binlog之後將binlog寫入本地的中繼日誌文件
5，slave本地的sql_thread應用中繼日誌到本地數據庫中

傳統的主從復制

對於傳統的主從復制,Slave連接至master的典型操作如下，就是手工指定slave要從master的哪個文件的哪個點開始執行其二進制日誌。

CHANGE MASTER TO 
MASTER_HOST=‘***.***.***.***‘,
MASTER_USER=‘username‘,
MASTER_PASSWORD=‘pwd‘,
MASTER_PORT = 3306,
MASTER_LOG_FILE=‘mysql-bin.000047‘,
MASTER_LOG_POS=3112;

潛在的問題：

1，數據異步復制，master提交事物並不需要與slave確認，binlog以異步的方式傳送到slave，很明顯，潛在的問題就是如果master宕機，可能存在沒有傳遞到slave的binlog，造成事物的丟失。
2，需要手工確認logfile以及logfile的偏移量

半同步復制

　　半同步復制最大的特點就是改進了傳統的主從復制潛在的主從不一致的問題，
　　半同步復制要求master提交事務之後，只要等到一臺slave接收到binlog並且成功寫入到中繼日誌中才算返回給客戶端成功提交的消息。
　　這樣就確保了master上所有的事物，都可以傳遞至至少一個slave，master宕機的情況下並不會丟失事物，解決了傳統復制潛在的問題1 ，但是問題2依舊。
　　潛在的問題：
　　1，依舊需要手工確認logfile以及logfile的偏移量

GTID復制

　　GTID是一個基於原始mysql服務器生成的一個已經被成功執行的全局事務ID，它由服務器ID以及事務ID組合而成。
　　這個全局事務ID不僅僅在原始服務器器上唯一，在所有存在主從關系 的mysql服務器上也是唯一的。
　　正是因為這樣一個特性使得mysql的主從復制變得更加簡單，以及數據庫一致性更可靠。

change master to 
master_user=‘username‘,
master_password=‘pwd‘ 
for channel ‘group_replication_recovery‘;

　　相對於傳統的主從復制，或者是提高了安全性的半同步復制，在搭建主從，或者是改變主從的時候，
　　操作方式都是需要手動指定binlog的文件以及文件的偏移量，說白了就是人為地去判斷slave應該從從master的哪個binlog中的哪個位置開始重放二進制日誌中的內容。
　　這樣勢必會增加手動操作以及人為判斷錯誤的可能性，不是太方便做主從或者故障轉移操作。

相對傳統的復制，GTID的優勢：
1、更簡單的搭建主從復制，以及實現故障轉移，不用以前那樣在需要手工指定log_file和log_pos。
2，正常情況下，GTID是連續沒有空洞的，因此主從庫出現數據沖突時，可以用添加空事物的方式進行跳過，跳過錯誤的事物更加方便。

多線程復制

　　半同步復制解決了傳統復制潛在的slave丟失master事物的問題，GTID復制簡化復制的實現，解決了傳統復制過於復雜的的問題，算是原始復制的兩個補丁。
　　從安全性和復雜程度兩個緯度改進了傳統復制，但是傳統復制依然潛在一個致命的問題，就是主從復制的延遲。
　　slave上的sql_thread應用中繼日誌到本地數據庫中，是一個單線程的操作，這樣面對大量的binlog，就可能存在效率上的問題，
　　多線程復制就是通過並行解析中繼日誌的方式，提要slave上sql_thread的執行效率，從而改善主從復制延遲的問題（當然也需要master的binlog做一定的優化）

MGR（MySQL Group Replication）

　　MGR，MySQL的組復制，不僅僅是復制的問題，可以認為是結合了傳統的復制，半同步復制（機制不一樣，多數節點同步提交），GTID復制等一系列特性的一種高可用解決方案，並且具備故障探測功能，自動檢測並剔除發生了故障的節點
　　因此說是一種高可用以及高擴展的解決方案，而不僅僅是完成復制的功能。

　　對於MGR的一些特性，一下引用自https://blog.csdn.net/jssg_tzw/article/details/69791330

　　高一致性，基於原生復制及paxos協議的組復制技術，並以插件的方式提供，提供一致數據安全保證；
　　高容錯性，只要不是大多數節點壞掉就可以繼續工作，有自動檢測機制，當不同節點產生資源爭用沖突時，不會出現錯誤，按照先到者優先原則進行處理，並且內置了自動化腦裂防護機制；
　　高擴展性，節點的新增和移除都是自動的，新節點加入後，會自動從其他節點上同步狀態，直到新節點和其他節點保持一致，如果某節點被移除了，其他節點自動更新組信息，自動維護新的組信息；
　　高靈活性，有單主模式和多主模式，單主模式下，會自動選主，所有更新操作都在主上進行；多主模式下，所有server都可以同時處理更新操作。

　　對於MGR，筆者僅簡單做過測試，搭建起來一如跟普通的復制並無太大差異，並不復雜，網絡上的評價也很高，大有一統各種第三方高可用技術的趨勢。
　　缺點是出來的時間太短（MGR是是MySQL官方於2016年12月推出的，對於互聯網來說，個人感覺超過已經不短了），可能存在這某些位置的問題。

總結

　　MySQL的復制，任何一種新方案的出現，其原理差異不大，都是為了解決前一種方案潛在的問題的，是作為前一種復制的提升或者說增強，開源沒有完美的解決方案，但是有不斷完善的解決方案，這不是開源的魅力之一嗎？
　　不同的復制其技術細節上可能有差異，但是本質性的東西是一樣的。
　　當然每一種復制都有其自身的細節上的特性，只能在實際應用中實踐了。
　　這也不由得令人想到各種數據中的各種隔離級別（isolation），雖然不能完全做類比，與復制一樣，每一種增強的隔離級別的，都是為解決前一種隔離級別中存在的問題而出現的。

MySQL復制相關技術的簡單總結