组复制官方翻译二、Group Replication Background

  1. 云栖社区>
  2. 博客>
  3. 正文

组复制官方翻译二、Group Replication Background

兰春 2019-01-15 15:29:45 浏览972
展开阅读全文

https://dev.mysql.com/doc/refman/8.0/en/group-replication-background.html

这一章主要描述一些组复制的背景

构建一个容错系统最常用的方法就是让组件冗余,换句话说就是组件即便被移除掉,整个系统还是能够正常对外提供服务
这无疑在不同层面上提出了更多的挑战
需要注意的是,复制结构的数据库系统必须思考的一个事实就是:他们需要维护和管理一堆不同的sever
此外,他们还必须解决分布式系统所面临的问题:比如 脑裂、网络分区等等

因此,最大的挑战就是去融合这种逻辑数据库,保证数据复制的一致性
换句话说,为了让不同server都同意这个系统的状态,他们每一台server的数据修改都必须验证一致
这就意味着他们需要运作的想一个状态机一样(分布式)

MySQL Group Replication提供了一套分布式状态机制复制管理方法

对于要提交的事务,这个group采取大部分原则来投票,让事务全局有序
决定commit还是拒绝这个事务都是由server自行判断,但是所有servers都会做出一样的决定
如果网络产生了分区,脑裂产生导致成员之间无法达成一致投票决定,那么这个系统会停止运行直到这个问题被解决
所以,他有一个内置、自动的脑裂包含机制在运行

以上所有的功能都是由Group Communication System (GCS) 协议来保证
它有错误检测机制、组成员通信服务、安全可靠的顺序一致消息分发
所有这些特性是搭建一个 数据完全一致性的系统 的关键要素
在一些非常核心重要的技术点上 罗列了Paxos 算法的实现,它扮演着组复制通信引擎的角色,至关重要

18.1.1 Replication Technologies

在了解MGR内幕之前,这里先主要介绍下相关的背景概念、以及概述
这章主要告诉我们,MGR需要什么,以及传统的异步复制和MGR直接的一些区别

18.1.1.1 Primary-Secondary Replication

传统的复制提供了一个简单的主从复制架构(Primary-Secondary)
primary就是master,secondary就是slaves,可以有多个slaves
master执行事务、commit事务,然后异步的将这些事务发送到slaves,让他们re-executed一遍(statement模式)或者 重新applied (ROW模式)
它是share-nothing架构,即所有server都有一份完整的数据copy

MGR_1

还有一种传统复制叫:半同步复制
它意味着:在commit的之前,master等待,直到slaves给master一个确认接收到事务的ack,master才恢复commit的操作

MGR_2

在上面的两幅图中,你能看到异步传统复制协议的基本架构,箭头代表client消息的流动和转变

18.1.1.2 Group Replication

组复制是一个实现了容错系统的技术
组复制集群就是一堆机器,他们之间通过消息进行沟通
communication 层:提供了一系列的保障机制,atomic message(原子广播) , total order message delivery(全局序列消息分发机制)

MGR在此基础上构建并实现了一个multi-master的复制协议,它可以在任何server上写数据
集群的本质就是多server,每个server可以独立的处理事务
但是所有的读写(RW)事务都必须经过集群的审核
所有的只读(RO)事务不受任何影响
换句话说,对于RW事务,group只需要决定它应该commit还是拒绝commit,因此事务操作并不是单方面(origi server)的决定
确切的说,当origin server准备进行事务commit的时候,这个server会自动广播这个写集
然后,一个全局排序的事务产生了
这意味着,所有的server都接收同样顺序的事务集
由于是有序的,所有server应用相同顺序,相同数据的写集,因此他们的数据也是一致的

然而,如果是并发写在不同server的场景会遇到冲突
因此,对应这种情况需要进行冲突检测,这个过程叫做认证 certification
如果两个并发事务在不同server同时执行,并且更新了相同的row,那么他们就是冲突的
那么它的解决方案就是,排在前面的事务会被标记commit,排在后面的会被拒绝(这个事务在origin server会回滚,其他server会被丢弃)

MGR_3

最后,MGR也是一种share-nothing架构,每个server都有一份完整的数据copy

18.1.2 Group Replication Use Cases

组复制提供了一个高容错性的系统,即使一些机器宕机,只要不是所有或者大多数机器不可用,那么整个系统还是可用状态
总结下来,MGR保证数据库持续可用

18.1.2.1 Examples of Use Case Scenarios

以下就是典型的MGR使用案例

  • Elastic Replication 可伸缩的复制
  • Highly Available Shards 高可用的分片
  • Alternative to Master-Slave replication 可选择master-slave架构
  • Autonomic Systems 完全自动化的系统

18.1.3 Group Replication Details

18.1.3.1 Failure Detection

它提供一个错误检测机制,可以找到或报告出哪些servers没有回应,哪些server挂了
在高一层次来将,错误检测机制就是一个分布式服务,用于提供哪些server挂掉或可能挂掉的情报信息
之后,如果组成员通过某种协议认证了这个嫌疑犯(可能挂掉的家伙)已经真的挂了,那么集群就会决定这个嫌疑犯真的的确挂了
这意味着,组的其他成员一致决定将这个嫌疑犯踢出集群

当Server A 在指定time-out时间内没有收到来自server B的回应,那么B就会被提升为嫌疑犯
如果一个Server被其他group成员隔离,那么它就会怀疑所有其他的成员都挂了
由于它不能达成投票的一致性认可(没有达到法定人数的确认),所以它认为的嫌疑犯就不能被确认为failed
如果一个Server在这种情况下被隔离,那么他是不能执行local事务的

18.1.3.2 Group Membership

MGR依赖组会员服务(Group Membership Service,简称GMS),它是内置的
它定义了哪些servers是online并加入了这个group,这些online servers经常被称为view
因此,这个组里面的任一online成员都有一个一致的view

如果servers同意让一个新server加入到这个group中来,那么这个group就好重新自动将其配置上,且重新触发形成一个新的view
如果一个server非自愿的离开了group,那么错误检测机制就开始识别,也会重新配置上一个新的view
上面提到的这些都需要一个协议,并且需要大多数人参与并认可的协议
如果这个group没有满足达到这个协议认可的要求,那么自动配置将不会起作用,并且该系统会被阻塞来防止脑裂的产生
最后,这意味着管理员需要手动介入来解决这个问题

18.1.3.3 Fault-tolerance

MGR 是在Paxos分布式算法构建实现的,以此它需要满足大多数活跃成员进行投票选举的策略。
有一个公式:n = 2 x f + 1 , n代表group的成员数,f代表允许挂掉的成员数 ,在这个公式下,整个集群是安全的

如果n=3,那么允许挂掉的server是1,也能满足要求,但是如果再挂一个呢, 其实就问题非常大了

集群成员数量n majority 可允许挂掉的server数量
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3

网友评论

登录后评论
0/500
评论
兰春
+ 关注