MGR復制架構
在MySQL 5.7.17版本正式推出組復制(MySQL Group Repliation MGR)，用來解決異步復制和半同步復制可能產生數據不一致的問題，組復制依靠分布式一致性協議(Paxos協議變體)來實現"數據最終一致性"，並提供單主模式下自動選主的高可用解決方案。
MySQL異步復制數據同步方式：
MySQL 半同步復制數據同步方式（AFTER SYNC）：
MySQL組復制數據同步方式：
在2N+1個節點組成的單主模式組復制集群中，主庫上一個事務提交時，會將事務修改記錄相關的信息和事務產生的BINLOG事件打包生成一個寫集(WRITE SET)，將寫集發送給所有節點，並通過至少N個節點投票通過才能事務提交成功。
在事務執行期間，會將：
1、事務操作生成的map event/query event/dml event等寫入BINLOG CACHE中(內存)
2、將Write Set寫入到Rpl_transaction_write_set_ctx中(內存)
在事務提交時，具體在MYSQL_BIN_LOG::prepare之后但是在MYSQL_BIN_LOG::ordered_commit之前，即事務相關的BINLOG Event還在BINLOG CACHE沒有寫入到BINLOG FILE前，將BINLOG CACHE中和Rpl_transaction_write_set_ctx中的數據進行處理並寫入到transaction_msg中，由gcs_module負責發送transaction_msg到各個節點，等待各節點進行事務認證。
由於transaction_msg中包含BINLOG信息，並在事務認證期間發送給MGR各節點，因此無需等待主節點的BINLOG落盤后再發送給備用節點。
每個MGR群集中的節點上，都存在IO線程和SQL線程，IO線程會解析transaction_msg獲取到BINLOG EVENT並保存到RELAY LOG中，再由SQL線程執行重放到輔助節點上。
從MGR復制原理上看，當主節點事務提交時，輔助節點上可能還未重放該事務對應的BINLOG，因此MGR仍屬於異步復制。
參考資料：
https://www.cnblogs.com/luoahong/articles/8043035.html
https://www.jianshu.com/p/9fb56fa4c6e4
https://www.jianshu.com/p/0bd0f6ba4741