mysql5.7.17 GA版发布，正式推出Group Replication(组复制) 插件，通过这个插件增强了MySQL原有的高可用方案(原有的Replication方案)，提供了重要的特性——多写，保证组内高可用，确保数据最终一致性。

1. 背景

在介绍组复制之前，我们先简单介绍传统的异步复制和半同步复制:

1.1 传统复制

传统mysql复制是完全异步化的复制。下图描述了传统复制的原理:

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

假设master发生宕机并且binlog还没来得及被slave接收，而切换程序将slave提升为新的master，就会出现数据不一致的情况！另外，在高并发的情况下，传统的主从复制，从节点可能会与主产生较大的延迟（当然mysql后续版本陆续做了优化，推出了并行复制，以此降低异步复制的延迟）。

1.2 半同步复制

基于传统异步存在的缺陷，mysql在5.5版本推出半同步复制。可以说半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay log并且响应给master以后，才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的，原理如下图所示:

因为slave接受relay log之后有可能apply失败。这个时候master其实不知道slave的失败，照常提交了这个事务。并且，半同步复制只确保一个slave能够收到relay log，多slave的场景下，不能保证其他节点正确收到relay log，由此，当发生master切换后，半同步复制一样也会出现数据不一致的情况。

1.3 组复制

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

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

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

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

2. 组复制介绍

一句话简介：基于分布式一致性协议Paxos实现数据最终一致性的MySQL插件。上面的介绍也已经大概地描述了组复制的相关概念以及它的诞生背景，下面我们关注于它的一些特性:

2.1 数据一致性保证

对于只读(RO)事务，组间实例无需进行通讯，就可以处理事务；但是对于读写(RW)事务，需要经过组内大多数节点决议，来决定该事务是否可以提交。

引用mysql官方博客对于读写事务提交过程的描述，解释了如何保证了组内节点间数据的一致性的:

To be precise, when a transaction is ready to commit at the originating server, the server will atomically broadcasts the write values (rows changed) and the correspondent write set (unique identifiers of the rows that were updated). Then a global total order will be established for that transaction. Ultimately, this means that all servers receive the same set of transactions in the same order. As a consequence, all servers apply the same set of changes in the same order, therefore they remain consistent within the group.

2.2 事务并发冲突处理

在高并发的多写模式（MGR的一种运行模式）下，节点间事务的提交可能会产生冲突，比如，两个不同的事务在两个节点上操作了同一行数据，这个时候就会产生冲突。首先，Group Replication（GR）能够识别到这个冲突，然后对此的处理采用乐观策略：依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，而后面的提交，会失败。

2.3 节点故障自动检测

GR自带故障检测机制，可以识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由其他节点决定是否将这个失效的节点从group里面剔除。当然，这是建立在满足大多数节点存活并且可以进行决议的前提上的。

2.4 组成员自动管理

GR自动维护组内节点的状态(在线？存活？挂掉？)，对于失效的节点，由其他节点决定是否剔除。对于新加入的节点，GR会自动维护它的视图与其他节点的视图保持一致。关于集群内节点的状态，可以通过performance_schema.replication_group_members表查看:

举个例子:

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 748703ac-dbcc-11e6-a668-90e2bac5d924 | 10.202.44.215 |       24801 | ONLINE       |
| group_replication_applier | 8f8bc352-2566-11e7-aa5e-d4ae52ab91b3 | 10.202.44.214 |       24801 | ONLINE       |
| group_replication_applier | 9c09340a-e04c-11e6-9916-0024e869a606 | 10.202.44.213 |       24801 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

如上有3个节点组成一个GR组，然后状态都是ONLINE（最正常的状态）。可以在组内的3个节点上都看到这个统一的视图。

有些同学可能会问，上面视图中的MEMBER_HOST是怎么显示成IP的，其实这个是通过my.cnf配置文件里面指定report_host而来的，若没有配置report_host，则MEMBER_PORT将显示为主机名

2.5 容错能力

GR基于分布式一致性算法实现，一个组允许部分节点挂掉，只要保证大多数节点仍然存活并且之间的通讯是没有问题的，那么这个组对外仍然能够提供服务。

假设一个GR由2n + 1个节点，那么允许n个节点失效，这个GR仍然能够对外提供服务。比如有3个节点组成的一个GR，可允许1个节点失效，这个GR仍然能够提供服务。