Group Replication

MySQL官方在5.7.17版本中以插件的形式引入了Group Replication，为用户又提供了一个高可用集群的选择。为什么又要提供一种高可用方案呢？其实之前的半同步和异步复制建立的主备集群或多或少是存在一些问题的。

一、MySQL的传统主从复制机制   

MySQL传统的高可用解决方案是通过binlog复制来搭建主从或一主多从的数据库集群。主从之间的复制模式支持异步模式(async replication)和半同步模式(semi-sync replication)。无论哪种模式下，都是主库master提供读写事务的能力，而slave只能提供只读事务的能力。在master上执行的更新事务通过binlog复制的方式传送给slave，slave收到后将事务先写入relay log，然后重放事务，即在slave上重新执行一次事务，从而达到主从机事务一致的效果。

 上图是异步复制(Async replication)的示意图,在master将事务写入binlog后，将新写入的binlog事务日志传送给slave节点，但并不等待传送的结果，就会在存储引擎中提交事务。

       上图是半同步复制(Semi-sync replication)的示意图，在master将事务写入binlog后，将新写入的binlog事务日志传送给slave节点，但需要等待slave返回传送的结果；slave收到binlog事务后，将其写入relay log中，然后向master返回传送成功ACK；master收到ACK后，再在存储引擎中提交事务。

对于异步复制存在主备不一致和丢失数据的风险。对于半同步复制，在发生主备切换时老的master可能会多一个事物（如果master没来得及将event发送给slave时发生了故障，这时主备发生了切换。因为最后的事物已经写到binlog，当老的master启动后会将其提交，从而导致了与新master之前的数据不一致）。

为了提供更好的高可用解决方案，官方引入了Group Replication。其解决了集群中各个节点数据不一致问题，并且增强了集群的自管理能力。

二、MGR原理  

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

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

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

2.1 组复制细节

2.1.1 故障检测

故障检测是提供关于哪些server可能已死的信息(猜测)的分布式服务。某个server无响应时触发猜测，组中其余成员进行协调决定以排除给定成员。如果某个server与组的其余成员隔离，则它会怀疑所有其他server都失败了。由于无法与组达成协议(因为它无法确保仲裁成员数)，其怀疑不会产生后果。当服务器以此方式与组隔离时，它无法执行任何本地事务。在线server列表通常称为视图，新成员server的加入离开，无论是自愿还是被迫的离开，该组都会动态地重新规划其配置，并触发视图更新。

2.1.2 组成员关系

    MySQL Group Replication依赖于组成员关系服务。这是内置于插件中的。它定义了哪些服务器在线并参与该组。在线服务器列表通常称为view。因此，组中的每个服务器都具有一致的视图，其是在某一时刻时刻主动参与该组的成员。

    服务器不仅必须同意事务提交，还要同意当前视图。因此，如果服务器同意新服务器成为组的一部分，则组将该服务器重新配置集成在其中，从而触发视图更改。相反的情况也会发生，如果服务器自愿离开组，则组会动态重新排列其配置并触发视图更改。

    请注意，当成员自愿离开时，它首先启动动态组重新配置。这会触发一个过程，所有成员必须在没有离开服务器的情况下就新视图达成一致。但是，如果一个成员不由自主地离开（例如它已意外停止或网络连接断开），则故障检测机制会实现这一事实，并建议重新配置该组。如上所述，这需要集团中大多数服务器的同意。如果该组无法达成同意（例如，它没有以多数服务器在线的方式进行分区），则系统无法动态更改配置因此组织脑裂的情况。最终，这意味着管理员需要介入并解决此问题。

2.1.3 容错

MySQL Group Replication构建于Paxos分布式算法的实现之上，以在服务器之间提供分布式协调。因此，它需要大多数服务器处于活动状态才能达到法定人数，从而做出决定。 这直接影响系统可以容忍的故障数量，而不会影响自身及其整体功能。假设一个GR由2n + 1个节点，那么允许n个节点失效，这个GR仍然能够对外提供服务。比如有3个节点组成的一个GR，可允许1个节点失效，这个GR仍然能够提供服务。若不满足大多数，所有事务写操作都会阻塞，直到集群满足大多数节点存活为止。