【MySQL 之Group Replication】

MySQL Group Replication is a MySQL Server plugin that provides distributed state machine replication with strong coordination between servers. Servers coordinate themselves automatically, when they are part of the same replication group.

 

 

一般主从复制，有三个线程参与，都是单线程：Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从)。复制出现延迟一般出在两个地方

1)SQL线程忙不过来(可能需要应用数据量较大，可能和从库本身的一些操作有锁和资源的冲突；主库可以并发写，SQL线程不可以；主要原因)

2)网络抖动导致IO线程复制延迟(次要原因)。

 

 

MySQL 5.6中，设置参数slave_parallel_workers = 4(>1)，即可有4个SQL Thread(coordinator线程)来进行并行复制，其状态为：Waiting for an evant from Coordinator。但是其并行只是基于Schema的，也就是基于库的。如果数据库实例中存在多个Schema，这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形，那基于库的并发就没有卵用。其核心思想是：不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致。

 

在MySQL 5.7中，引入了基于组提交的并行复制(Enhanced Multi-threaded Slaves)，设置参数slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，即可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想：一个组提交的事务都是可以并行回放(配合binary log group commit)；slave机器的relay log中 last_committed相同的事务(sequence_num不同)可以并发执行。

 

 

Group Replication(组复制)

组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的服务器组。通信层提供了很多保证，例如原子消息和总消息序号的传递。通过这些强大的特性，我们可以构建更高级的数据库复制解决方案。

MySQL组复制构建在这些属性和抽象之上，并实现多主复制协议的更新。实质上，复制组由多个数据库实例组成，并且组中的每个实例都可以独立地执行事务。但是所有读写(RW)事务只有在被组批准后才会提交。只读(RO)事务不需要在组内协调，因此立即提交。换句话说，对于任何RW事务，组需要决定是否提交，因此提交操作不是来自始发服务器的单向决定。准确地说，当事务准备好在始发服务器上提交时，该始发服务器原子地广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后为该事务建立一个全局总序号。最终，这意味着所有服务器以相同的顺序接收同一组事务。因此，所有服务器以相同的顺序应用相同的一组更改，因此它们在组内保持一致。

 

但是，在不同服务器上并发执行的事务之间可能存在冲突。通过检查两个不同的并发事务的写集合来检测这样的冲突，这个检查过程称为认证(certification)。如果在不同的服务器上执行的两个并发事务更新同一行，则会出现冲突。解析过程会这么做，首先发起的事务在所有服务器上提交，而后发起的事务将在源服务器上回滚，并由组中的其他服务器删除。这实际上是一个分布式环境下“优先提交者赢”的规则。

最后，组复制是一种无共享复制方案(shared_nothing)，即每个服务器都有自己的整个数据副本。 上图描述了MySQL组复制协议，并通过将其与MySQL复制(或甚至MySQL半同步复制)进行比较，您可以看到一些差异。注意，为了清楚起见，这个图片中缺少一些基本的共识和Paxos相关信息。

 

 

Group ReplicationUse Cases(组复制应用场景)

组复制使您能够通过在一组服务器中复制系统状态来创建具有冗余的容错系统。因此，即使一些服务器发生故障，只要它不是全部或大多数，虽然可能降低系统性能或可扩展性，但系统仍然可用。单一服务器故障是隔离和独立的。它们由group membership service跟踪，它依赖于分布式故障检测器，分布式故障检测器能够在任何节点成员自愿地或由于意外停止而离开群组时发出信号。分布式恢复过程能够确保当有新节点加入组时，该节点会自动更新到最新。Multi-master特性确保即使在单个服务器故障的情况下也不会阻止更新。因此，MySQL组复制保证数据库服务持续可用。

 

不过需要重点理解，尽管组复制存在高可用，但连接到它的客户端必须被重定向或故障转移到不同的服务器。这不是组复制尝试解决的问题，而是连接器，负载均衡器，路由器或一些其他中间件更适合处理这个问题。

 

总而言之，MySQL组复制提供了高可用性，高弹性，可靠的MySQL服务。

 

Examples of Use Case Scenarios(应用案例)

·弹性复制 - 需要非常流畅的复制基础架构的环境，其中服务器的数量必须动态增长或收缩，尽可能减少副作用。例如，云的数据库服务。

·高可用分片 - 分片是实现写扩展的常用方法。使用MySQL组复制实现高可用性分片，其中每个分片映射到复制组。

·替代主从复制 - 在某些情况下，使用单一主节点可能使其成为单点争用。在某些情况下，写入整个组可能更具可扩展性。

·自动化系统 - 可以将MySQL组复制当做一个纯粹的自动化复制系统

 

 

 

 

组复制中的一些限制

1数据表要使用innodb存储

2表上要有主键

3使用ipv4

4网络的性能要好

5复制要使用行复制的模式

6gtid模式要打开

7事务的savepoints不被支持

8多master上不支持外键

9多主上serializable事务隔离级别不会被支持