（转）MySQL Group Replication介绍

bestjoe

　　这是一个振奋人心的消息！
　　2016-12-12，一个重要的日子，mysql5.7.17 GA版发布，正式发布了Group Replication(组复制) Plugin，增强了MySQL原有的高可用方案(原有的高可用方案是指mysql主从架构)，提供了重要的特性——多写，保证组内高可用，数据强一致性。
　　1. 背景
　　在介绍组复制之间，我们先简单介绍传统的复制和半同步复制:
1.1 传统复制
　　传统mysql复制是完全异步化的复制。下图描述了传统复制的原理:

http://mysqlhighavailability.com/mysqlha/gr/doc/_images/async_replication_diagram.png

　　master事务的提交不需要等待slave>1.2 半同步复制
　　半同步复制是传统复制的变种，在master事务的commit之前，必须确保slave收到relay log并且响应给master以后，才能进行事务的commit。

http://mysqlhighavailability.com/mysqlha/gr/doc/_images/semisync_replication_diagram.png

　　因为slave接受relay log之后有可能apply失败。这个时候master其实不知道slave的失败，照常提交了这个事务。由此，半同步复制一样也会出现数据不一致的情况。
1.3 组复制

http://mysqlhighavailability.com/mysqlha/gr/doc/_images/gr_replication_diagram.png

　　引入组复制，是为了解决传统复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的强一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。
　　一个replication group由若干个节点(数据库实例)组成，组内各个节点维护各自的数据副本(Share Nothing)，通过一致性协议实现原子消息和全局有序消息，来实现组内实例数据的强一致。
2. 组复制介绍
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>

2.2 事务冲突处理
　　在高并发的情况下，节点间读写事务的提交可能会产生冲突，比如，两个不同的事务在两个节点上操作了同一行数据，这个时候就会产生冲突。首先，Group Replication是能够识别到这个冲突，然后对此的处理是，依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，而后面的提交，会失败。
2.3 故障检测
　　Group Replication内部有故障检测机制，可以识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由其他节点决定是否将这个失效的节点从group里面剔除。
2.4 组成员管理
　　replication group需要维护组内节点的状态(在线？存活？挂掉？)，对于失效的节点，由其他节点决定是否剔除。对于新加入的节点，需要维护它的视图与其他节点的视图保持一致。
2.5 容错能力
　　组复制基于分布式一致性算法实现，一个组允许部分节点挂掉，只要保证绝大多数节点仍然存活并且之间的通讯是没有问题的，那么这个组对外仍然能够提供服务。
　　假设一个复制组由2n + 1个节点，那么允许n个节点失效，这个复制组仍然能够对外提供服务。比如有3个节点组成的一个复制组，可允许1个节点失效，这个复制组仍然能够提供服务。
Group>　　由此可以看出，复制组由奇数个节点组成为佳。
2.6 两种模式
　　mysql5.7.17 Group Replication提供了single-primary和multi-primary两种模式。single-primary mode 组内只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持强一致；而multi-primary mode 为多写，即写会下发到组内所有节点，组内所有节点同时可读，也是能够保证组内数据强一致性。一个group的所有节点必须配置使用同一种模式，不可混用。
2.6.1 Single-Primary Mode
　　这个模式下，group内只有一台节点可写可读，其他节点只可以读。对于group的部署，需要先跑起primary节点(即那个可写可读的节点)，然后再跑起其他的节点，并把这些节点一一加进group。其他的节点就会自动同步primary节点上面的变化，然后将自己设置为只读模式。
　　当primary节点意外宕机或者下线，在满足大多数机器存活的情况下，group内部发起选举，选出下一个可用的读节点，提升为primary节点。

　　primary选举根据group内节点的UUID按字典序来选择，即存活的节点按UUID字典序排列，然后选择排在最前的节点作为新的primary节点。

http://mysqlhighavailability.com/mysqlha/gr/doc/_images/single-primary-election.png

　　【重要】 在切换primary期间，mysql group不会重定向应用所持有的连接。这需要应用层或者中间件层去保证。
　　如何查看group内哪个节点是作为primary节点，官方提供了一个方法:
mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';　　
+--------------------------------------+
　　
| VARIABLE_VALUE                       |
　　
+--------------------------------------+
　　
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
　　
+--------------------------------------+1 row in set (0,00 sec)12345671234567
　　得到的是实例节点的UUID
2.6.2 Multi-Primary Mode
　　多主模式，即多写，没有选择新primary的概念，group内的所有机器都是primary节点，同时可以进行读写操作，并且数据是一致的。让我等屌丝看到了多活方案的希望啊…

http://mysqlhighavailability.com/mysqlha/gr/doc/_images/multi-primary.png

2.7 Requirements&Limitations
2.7.1 Requirements
　　部署group replication有以下需求:
　　1) 架构上

• 　　存储引擎必须为innodb
  
• 　　每个表必须提供主键
  
• 　　只支持ipv4，网络带宽要好
  
• 　　一个group最多只能有9个节点
  

　　2) 配置上
　　针对my.cnf，需要指定如下配置:
# Binary Log must be active.　　
log-bin[=log_file_name]
　　

　　
# Binary Log Format must be set to ROW.
　　
binlog-format=row# Global Transaction Identifiers must be turned on.
　　
gtid-mode=ON# Replication applier needs to have replication metadata repositories stored in system tables.
　　
master-info-repository=TABLErelay-log-info-repository=TABLE# Transaction write set extraction must be enabled.transaction-write-set-extraction=XXHASH64
　　

　　
# Servers need to log binary logs that are applied through the replication applier.
　　
log-slave-updates
　　

　　
# Replication event checksums are not supported.
　　
binlog-checksum=NONE1234567891011121314151617181920212212345678910111213141516171819202122
2.7.2 Limitations
　　以下列举使用group replication的限制:

• 　　不支持Replication event checksums，需要在my.cnf里面配置，在上节已经提及
  
• 　　不支持Savepoints
  
• 　　multi-primary mode部署方式不支持SERIALIZABLE事务隔离级别
  
• 　　multi-primary mode部署方式不能完全支持级联外键约束
  
• 　　multi-primary mode部署方式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败)
  

　　转载由：http://blog.csdn.net/d6619309/article/details/53691352