MySQL 异步复制，半同步复制，组复制区别

MySQL异步复制

master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不关心。slave接收到master binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知。

这种方法的缺点是及时slave已经失败了，但是master无法感知，那么主从复制相当于变成了单点实例，系统的安全性会降低。当master发生宕机并且binlog还没来得及被slave接收，而切换程序将slave提升为新的master，就会出现数据不一致的情况！另外，在高并发的情况下，传统的主从复制，从节点可能会与主产生较大的延迟。

 

MySQL半同步复制

基于传统异步存在的缺陷，mysql在5.5版本推出半同步复制。可以说半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay log并且响应给master以后，才能进行事务的commit。相当于添加多了一个从库反馈机制，这个有两种方式设置：

after_commit: 主库执行完事务后，主库提交commit ，同步binlog给从库，从库ack反馈接收到binlog，反馈给客户端，释放会话；(主库生成binlog，主库提交，再同步binlog，等ACK反馈，返回客户端)

after_sync:主库执行完事务后，同步binlog给从库，从库ack反馈接收到binlog，主库提交commit，反馈给客户端，释放会话；(主库生成binlog，再同步binlog，等ACK反馈，主库提交，返回客户端)

但是slave对于relay log的应用仍然是异步进行的，原理如下图所示:

 

MySQL组复制(MGR)

基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）

由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。    

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。

一个复制组由若干个节点(数据库实例)组成，组内各个节点维护各自的数据副本(Share Nothing)，通过一致性协议实现原子消息和全局有序消息，来实现组内实例数据的一致。

MGR的解决方案目前的一些局限性
    存储引擎必须为Innodb，即仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测.在MySQL Group Replication中，事务以乐观形式执行，但是在提交时检查冲突，如果存在冲突，则会在某些实例上回滚事务，保持各个实例的数据一致性，那么，这就需要使用到 事务存储引擎，同事Innodb提供一些额外的功能，可以更好的管理和处理冲突，所以建议业务使用表格使用inndb存储引擎，类似于系统表格mysql.user使用MyISAM引擎的表格，因为极少修改及添加，极少出现冲突情况。
    每个表必须提供主键.每个需要复制的表格都必须定义一个显式主键，注意跟隐式主键区分（使用Innodb引擎的表格，如果没有指定主键，默认选择第一个非空的唯一索引作为主键，如果没有，则自动创建一个6个字节的rowid隐式主键）。这个主键能在冲突发生时启动极其重要的作用，同时，能够有效提高relay log的执行效率。
    官网建议使用READ COMMITTED级别，除非应用程序依赖于REPLEATABLE READ，RC模式下没有GAP LOCK，比较好支持Innodb本身的冲突检测机制何组复制的内部分布式检测机制一起协同工作。不支持SERIALIZABLE隔离级别。
    不建议使用级联外键，如果旧库本身有外键，业务上无法去除并且使用的是多主模式，那么，请配置 group_replication_enforce_update_everywhere_check ，强制检查每个组成员的级联检查，避免多主模式下执行级联操作造成的检测不到的冲突。
    只支持ipv4，网络需求较高
    必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set;
    目前一个MGR集群组最多支持9个节点;
    不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚;
    二进制日志binlog不支持Replication event checksums;
    多主模式(也就是多写模式) 不支持SERIALIZABLE事务隔离级别;
    多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败);

    
MGR基础结构要求，见官方文档Group Replication Requirements
    引擎必须为innodb，因为需事务支持在commit时对各节点进行冲突检查
    每个表必须有主键，在进行事务冲突检测时需要利用主键值对比
    必须开启binlog且为row格式
    开启GTID，且主从状态信息存于表中（–master-info-repository=TABLE 、–relay-log-info-repository=TABLE），–log-slave-updates打开
    一致性检测设置–transaction-write-set-extraction=XXHASH64