MySQL Group Replication基于Paxos协议的状态机复制。之前高可用方式，本质都是Master-Slave。MySQL 5.7开始无损半同步复制（lossless semi-sync replication），提升数据复制强一致性
概要：异步复制、半同步复制、组复制对比，特性，影响
一、对比其他复制
1、MySQL异步复制
master事务提交不需slave确认，不care slave是否接收到master的binlog（缺点：1、slave接受或应用失败，m无法感知，master宕机s为新m，数据不一致！）
缺点：2、高并发的主从复制，从与主较大延迟（并行复制优化，降低延迟）
slave收到master binlog先写relay log，异步执行relay log的sql应用到自身。
优点：性能最好，无需等待传输结果
2、MySQL半同步复制
主库在binlog commit后将binlog发送到从库，从库接收到binlog后，落盘relay log后回复ack；主库收到ack再进行提交
在具体的版本中，5.5、5.6的半同步机制做了优化，主库等待从库ack的时机不同：5.5 采用after-commit，即在binlog sync、innodb commit后再等待从库ack，这会造成其他session可以看到已提交的事务，如果此时发生主从切换，会产生幻读；5.6采用after-sync，把等待ack的时机提前到iinnodb commit之前，在binlog sync后等待从库ack，其他session看不到等待提交的事务，避免了幻读问题。下图是采用after-sync的半同步方式。
3、MySQL组复制
5.7.17推出组复制MGR，依靠分布式一致性协议(Paxos变体)，实现最终一致性：组内大多数节点（N / 2 + 1）决议通过，事务才可提交
例：3个节点组成一个复制组，Consensus层为一致性协议层，2个节点通过才提交
各节点维护各自数据副本(Share Nothing)，通过一致性协议实现原子和全局有序消息，实现组内一致。
ps：针对只读（RO）事务则不需组内同意，直接 COMMIT
二、特性
数据一致性保障：集群大部分节点收到日志
Fault Tolerance: 故障（包括脑裂）依然可用，双写对系统无影响
三、影响
仅支持InnoDB表，一定要一个主键，做write set冲突检测；
必须开GTID特性，二进制日志格式为ROW，用于选主与write set
COMMIT失败，类似快照事务隔离级别失败场景
MGR集群最多支持9个节点
不支持外键于save point特性，无法做全局间的约束检测与部分回滚
二进制日志不支持binlog event checksum
