（转）MySQL Group Replication介绍

这是一个振奋人心的消息！

2016-12-12，一个重要的日子，mysql5.7.17 GA版发布，正式发布了Group Replication(组复制) Plugin，加强了MySQL原有的高可用方案(原有的高可用方案是指mysql主从架构)，提供了重要的特性——多写，保证组内高可用，数据强一致性。

1. 背景

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

1.1 传统复制

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

master事务的提交不须要等待slave relay的响应。relay log老是异步地发送到slave上去执行。在高并发的状况下，传统的主从复制，从节点可能会与主产生较大的延迟，此时若是主节点出现异常，那么就会出现数据不一致的状况，数据可能会丢！

1.2 半同步复制

半同步复制是传统复制的变种，在master事务的commit以前，必须确保slave收到relay log而且响应给master之后，才能进行事务的commit。

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

1.3 组复制

引入组复制，是为了解决传统复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(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 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 事务冲突处理

在高并发的状况下，节点间读写事务的提交可能会产生冲突，好比，两个不一样的事务在两个节点上操做了同一行数据，这个时候就会产生冲突。首先，Group Replication是可以识别到这个冲突，而后对此的处理是，依赖事务提交的时间前后顺序，先发起提交的节点可以正确提交，然后面的提交，会失败。

2.3 故障检测

Group Replication内部有故障检测机制，能够识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由其余节点决定是否将这个失效的节点从group里面剔除。

2.4 组成员管理

replication group须要维护组内节点的状态(在线？存活？挂掉？)，对于失效的节点，由其余节点决定是否剔除。对于新加入的节点，须要维护它的视图与其余节点的视图保持一致。

2.5 容错能力

组复制基于分布式一致性算法实现，一个组容许部分节点挂掉，只要保证绝大多数节点仍然存活而且之间的通信是没有问题的，那么这个组对外仍然可以提供服务。

假设一个复制组由2n + 1个节点，那么容许n个节点失效，这个复制组仍然可以对外提供服务。好比有3个节点组成的一个复制组，可容许1个节点失效，这个复制组仍然可以提供服务。

Group Size	Majority	Instant Failures Tolerated
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

由此能够看出，复制组由奇数个节点组成为佳。

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节点。

【重要】 在切换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节点，同时能够进行读写操做，而且数据是一致的。让我等屌丝看到了多活方案的但愿啊…

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