什么是MGR?

MGR是Mysql Group Replication(组复制)的缩写,Mysql5.7之后是以一个Mysql插件的形式集成在Mysql中,用于创建可伸缩、高可用、可容错的复制架构,是Mysql集群的一种形式。MGR包括一套内置的组成员服务,包括节点的自动加入、离开,故障检测等机制。

常见的创建容错系统的方法是使用冗余组件,而一旦使用冗余组件,就需要管理多个的服务器,其中就会遇到一些 棘手的问题,例如常见的网络分区、脑裂问题。数据库容错系统的挑战就是如何让集群中的每个服务器都同意当前系统的状态以及每一个更改的数据,也就是让服务器在每个数据库状态转换上达成一致。这样它们就可以作为一个单一的数据库进行开发,或者它们最终会收敛到相同的状态。这意味着它们需要作为一个(分布式)状态机来操作。

MGR正是Mysql提供的状态机复制技术。在MGR中每个服务器都能看到其他组节点的状态,在MGR中称之为视图(view),MGR内置group membership service,为每个节点提供一致的视图,节点的离开、加入都会触发视图的改变,而因为网络异常的原因退出的节点,也会有相应的故障检测机制来发现。

MGR的一个重要特点是对于要提交的事务,组中的大多数必须在全局事务序列中约定给定交易的顺序,决定提交或中止事务是由每个服务器单独完成的,MGR保证所有的服务器都做出相同的决定。

所有这些功能都依赖于底层的节点间通信和协调算法。在Mysql中被称为Group Communication System (GCS),它提供了故障检测机制、组成员服务以及安全且完全有序的消息传递,其底层基于paxos算法。

主从复制

传统Mysql复制技术为主从复制,一般存在一个master服务器,一个或者多个slave服务器,master执行事务并且提交,稍后binlog被复制到slave,在slave中基于状态、基于行进行复制。它是一个无共享的系统,所有服务器在默认情况下都有完整的数据副本。

异步复制

半同步复制

半同步复制市在master提交之前需要等待binlog传到slave之后,slave恢复ACK给到master,用以确认master执行的事务已经传到了slave,注意这不保证salve应用了这些事务。

组复制本质上多主更新到处复制的协议,其依赖于底层的组成员间的通讯协议,底层通讯保证了消息的顺序以及原子性。一个重要的特点是组中的成员都是独立地执行事务,但是事务的提交则需要组的协调批准。(只读事务例外,不需要经过组的批准。)

如上图所示,事务将

组复制同样是一个无共享的复制方案,其中每个服务器都有自己的全部数据副本。

组复制使得Mysql能够实现容错,在部分节点崩溃等情况下,能够实现自动检测和恢复,保证数据库本身还是连续可用的。另外,MGR只是保证数据库的可用性,还需要负载均衡或者路由器等配合,因为可能会出现IP转移等问题,而这部分功能显然是使用独立中间件更合适。

会被发送到多个组成员中,由组成员单独执行,如果存在两个不同的事务,在不同的组成员中并发执行,更新相同的行,这就可能会造成冲突,此时因为不是在单节点上,所以还无法使用单节点的加锁机制在解决此问题。组复制中使用certify过程来解决此问题,在执行事务之前,会检查两个不同并发事务的写集来检测此类冲突。

故障检测机制MGR底层实现了分布式故障检测服务,能够自动检测哪些服务器可能存在问题,并经过组内其他成员同意之后将这些服务器排除出组。相对的,对于一个服务器来说,当它从组中分离出来之后,它会怀疑组内所有的其他成员都失败了,由于此时无法实现“过半数”的同意,所以这个服务器的这种怀疑没有结果,它也无法单独对外提供服务。

一致性组内视图视图是组复制中组内成员都同时维护着的对于组内其他成员的状态表。由于MGR决策过程中需要组内成员的协调,故保持对于组内成员的一致性视图是必要的。引起视图变更的情况有两种:

新成员的主动加入或者旧成员主动离开,都会触发一次成员的变更,并通知到其他成员,等待其他成员大多数同意达成一致。

组内成员的非自动或者意外断开,故障检测机制将会主动发现,并触发一个成员变更,同样的需要等到成员大多数同意才能更新视图,如果无法达成一致,例如剩下的成员无法实现过半数同意的情况,那么就无法形成一致,这会造成脑裂问题。

容错性MGR底层基于paxos分布式算法,组内节点数n,则允许出错的节点数f=(n-1)/2。以下表格说明了这种关系:

performance_schema.replication_group_member_stats认证与applier过程的一些统计数据,通过这个表格你可以知道applier队列的增长,有多少冲突,多少事务经过检查。

performance_schema.replication_group_members集群内节点的信息,如端口,IP,状态等。

performance_schema.replication_connection_statusmaster和slave之间连接的I/O线程的状态

performance_schema.replication_applier_statusgroup_replication_applier的状态

group_replication_recovery用于在组成员间传输事务日志

group_replication_applier用于应用来自于组的事务运行模式

使用my.cnf中配置的参数:group_replication_single_primary_mode

组复制插件架构

数据操作语句

数据定义语句

分布式恢复

分布式恢复基础一个成员加入一个组的过程,称为distributed recovery.在一个成员加入组的时候发生的所有的事务和成员事件都会应用在新加入的服务器上。在第一阶段,加入该组的服务器选择该组中的一个在线服务器,作为它丢失的状态的提供者,提供者负责提供服务器加入组的所有数据,直到它加入到组中。这是通过依赖于一个标准的异步复制通道来实现的,它是在提供者和连接组的服务器之间建立的。通过这个复制通道,提供者提供的数据被复制一直到视图的改变。连接组的服务器接收到二进制日志之后应用这些二进制日志。当二进制日志被复制时,加入该组的服务器也会缓存在组内交换的每一个事务。换句话说,它是在监听在加入该组织后正在发生的事务,同时它正在从捐赠者那里应用缺失的状态。当第一个阶段结束,并且向供体的复制通道关闭时,连接组的服务器将启动第二阶段:追赶在此阶段,加入该组的服务器将继续执行缓存的事务。当排队等待执行的事务数量最终达到零时,其将会声明自己的状态为ONLINE。

从某一个时间点恢复

查看变更

分布式恢复的使用建议和限制

可观察性

组复制性能