参考国外MySQL大神的博客lefred.be，理解一下Group Replication是同步还是异步的，原文地址请戳：MySQL Group Replication… synchronous or asynchronous replication ?
经过前面文章的讨论，我们知道，Group Replication利用分布式一致性协议，来保证数据的最终一致性。我们知道，传统的复制，是异步复制的。那么，对于组复制，到底它是异步的还是同步的？
Group Replication = 组复制
理解Replication
通俗来说，复制是指主库（master）上写的数据，能够在从库（slave）上保持同步。复制涉及以下步骤：
- 主库本地提交更新
- 主库生成binlog event
- 主库传输binlog event到从库上
- 从库将传输得到的binlog event追加到relay log中
- 从库应用relay log中的binlog event，实现数据的同步
组复制仍然是异步的复制
实际上，对于组复制来说，只有【第3步】是同步的，剩下的步骤都是异步的。在组复制中，步骤3相当于发送write set，write set中包含一系列全局有序的bin log event。而对于binlog event add到 relay log以及最后对于relay log的应用，都是异步的。
另外一点很重要，只有当事务commit的时候，才会发送write set，也就是将当前事务所涉及到的binlog event在组内进行传播。假设你的事务是个大事务，产生了很多binlog event，那么这个事务的提交将是一个耗时的操作，它将会等待组内的大多数（majority）存活节点共同决议这个提交，才会返回。
用一组图来分析说明这个过程：
这里我们假设node1-3组成MGR集群，模式为单主模式，即node1为主，node2和node3为从节点
在主节点node1上开启事务，执行一系列的操作:
接着事务提交，事务内所产生的binlog封装成全局有序的write set，传播到组内其他节点:
接收完binlog的节点就可以自行进行certify阶段，决定这些binlog event是否能够并自己本地应用？会不会产生冲突？
当主节点收到大多数节点的certify阶段完成后，就可以返回并响应事务的提交，而不用等待所有的节点，还有接下来binlog add到relay log再从relay log应用数据这些阶段，通通不用等
其他节点对于binlog追加到relay log以及最后的应用，都是独立进行的:
由于数据的应用是异步的操作，实际上解释了组复制只能保证数据最终一致性这个结论。也就说，很有可能你会在从节点上，读取不到你刚刚提交的记录！理解组复制是最终一致性的，这一点很重要。另外，上面也总结了，组复制，实际上还是异步的复制。