（转）MySQL Group Replication介绍
这是一个振奋人心的消息！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
页:
[1]