GR运维手册 - 第一册 苦海岸边,GR的基础知识

作者简介:

刘伟 云和恩墨开源解决方案事业部首席架构师

多年一线互联网企业DBA经历,对MySQL、NoSQL,PostgreSQL等各类开源数据库均有涉猎,负责开发管理过数千实例规模数据库项目,并带领团队开发了MySQL数据库的监控、备份等自动化组件,对超大规模数据库运维平台的开发及管理有丰富经验。

引言:Group Replication(后文简称GR)是一个MySQL的多主share nothing集群。接下来的这系列分享中,将包含MySQL Group Replication的基础架构以及相关知识,详细的操作步骤在后文说明。

在正文开始之前,我们先来谈谈重要的事情:关于这个题目。

不知道在座各位看到苦海无边是什么反应,反正小编是受到了惊吓,非得要作者给个说法。恩,作者是这样回答的:

如是我闻。世传金丹大道,七返九转,可以至苦海岸边。苦海岸上,出神入化种种次第,传述不明。今得一十三部经书,述阳神化身诸次第修行。

话说说的这是啥?!这不是欺负小编没有读过书嘛。终于在小编再三要求下,作者用人类的语言表达了这个观点:

MySQL的传统高可用比如主从以及双机HA等方案讲述者不在少数,但Group Replication以及Galera等比较新的高可用架构,网上资料麟角凤毛不说,大部分都是在讲安装初始化等基础内容,对监控,高可用等其他内容关注不多,这次趁Group Replication刚刚发布,对常规的种种话题做一些总结。

这次听懂了吗?听懂了。好的那我们开始学习!

MySQL Group Replication架构

从实际的部署情况看,MySQL Group Replication 部署三个或者更多节点,节点之间通过分布式协议沟通。所有节点的地位都是平等的,并不存在一个管理节点。每个节点都会维护一个集群的节点列表,并根据自己与其他节点之间的通讯情况进行动态变更。

Group Replication 程序结构

在MySQL的底层,GR增加了另外的API层来实现所需要的功能。

程序结构上,GRAPI主要分为三部分:

  • capture 追踪当前正在执行的事务的上下文。
  • applier 执行远程事务传输到本地的日志到本地数据库。
  • recovery 负责分布式环境下的节点恢复,以及相关的数据回追,失败处理等。

在这几个主要API层的下面,是统一的复制协议逻辑处理层,这一层主要是统一应用层的各种调用。在更下层,则是通用程度更高的分布式通讯层,处于调用便利,分布式通讯曾对上提供使用的API,API的下面,是Paxos实现的分布式通讯协议组件,这个组件与集群中其他节点一起,形成一个虚拟概念化的分布式集群。

MySQL Group Replication 使用 单个事务,必须只能发生在一个节点(集群内分布式事务没有意义,因为所有节点的数据都是一样的)。

每次一个事务在一个节点提交的时候,就会发送所修改的数据到所有节点,检查期间是否有修改冲突(比如修改了别的节点已经修改并提交成功的事务的数据),如果发现冲突,本事务回滚。如果没有冲突,则可以直接提交成功。 对于非执行事务的远程节点,如果事务判断为执行成功,远程发送过来的数据,会被保存在本地的一个relay log里面(注意,与常规主从同步使用的relay log不是同一组),之后由从库的applier线程采用正常主从同步(目前已经支持LOGICAL_CLOCK并行执行)的方式执行掉对应的relay log。

这里有一个临界点,如果一个事务刚刚被写入relay log,还没有来得及执行掉,这时候有一个事务的执行涉及了相关的数据,那么后来的这个事务在执行阶段可以执行成功,但是必定会在提交阶段失败的。

多节点写事务冲突如下:

假设我们有三节点的集群,其中有节点1,节点2,节点3.

现在在节点1上发起事务1,节点2上发起事务2,都是对同一行的delete,操作顺序如下:

1. 节点1>begin 2. 节点2>begin 3. 节点1>delete 4. 节点2>delete 5. 节点2>commit 6. 节点1>commit # 这一步会失败,整个事务会被回滚。

MySQL Group Replication 目前的限制 1. 所有涉及的数据都必须发生在InnoDB存储引擎的表内。

2. 所有的表必须有明确的主键定义。 3. 网络地址只支持IPv4。 4. 需要低延迟,高带宽的网络。 5. 目前集群限制最多允许9个节点。 6. 必须启用binlog。 7. binlog 格式必须是row格式。 8. 必须打开gtid模式。 9. 复制相关信息必须使用表存储。 10.事务写集合(Transaction write set extraction)必须打开。(这个目前与savepoint冲突,这也是导致mysqldump无法备份GR实例的原因) 11. log slave updates必须打开。 12. binlog的checksum目前不支持。 13. 由于事务写集合的干扰,无法使用savepoint。 14. SERIALIZABLE 隔离级别目前不支持。 15. 对同一个对象,在集群中不同的实例上,并行地执行DDL(哪怕是相互冲突的DDL)是可行的,但会导致数据一致性等方面的错误,目前阶段不支持在多节点同时执行同一对象的DDL。 16. 外键的级联约束操作目前的实现并不完全支持,不推荐使用。

MySQL Group Replication 的一些问题的回复(官方文档) Q:MySQL Group Replication最多允许几个节点?

目前代码里面写死了9个,如果想多加节点进去会拒绝加入。

Q:节点之间相互是怎么通讯的?

节点直接是通过点到点的tcp连接通讯的,这些连接只用于节点之间的消息通讯。

Q:group_replication_bootstrap_group 选项的主要作用是什么?

这个选项主要用于初始化一个新的集群,第二个节点以及后续节点可以通过加入申请加入到这个节点。

Q:集群节点有两个地方需要加入到集群的操作,一个是集群创建的时候,另外一个是关闭并重启集群的时候。我应该在什么地方设置安全验证?

如果需要设置安全相关(用户名密码,SSL)的东西,需要在每个节点上都使用change master语句设置。

Q:Group Replication是否可以用于写负载的横向扩展?

不可以。MySQL Group Replication是share nothing的全量复制方案。集群中的每个节点都包含了数据库所有的数据。如果一个节点写入了N字节的数据,那么所有节点都会写入N字节的数据,所有数据操作都会被复制到所有节点执行。当然,其他节点并不是直接运行源事务的所有操作。事务传输是通过row格式传输的,其实际的应用速度会更好一点。

实际使用中,处于控制带宽以及响应时间的目的,也会使用更优化的row格式传输到目标节点以减少IO的消耗操作。

总的来看,可以使用Group Replication来扩展处理速度,也就是在集群的不同节点处理不同事务,降低单个节点的事务处理压力。

Q:与传统的简单复制模式相比较,同样的负载情况下,Group Replication是否需要更好的带宽以及CPU?

当然会有一些负载上的增加,但实际上很难估计增加了多少,比如节点数量的不同,对带宽的需求也是完全不同的。由于所有节点之间都需要沟通,3节点和9节点的带宽需求差距很大。另外考虑到同步以及消息处理,额外的内存和CPU消耗肯定也是必要的。

Q:是否可以部署Group Replication到广域网上?

不建议这么做。快速的网络是保障GR可用性能的基础,在一般情况下,可以采用压缩等基础,降低带宽方面的消耗,单如果出现丢包,会导致重传以及更高的网络延迟,整个系统的吞吐量以及延迟会到一个无法接受的程度。当然,如果非要部署,当然也是可以的。但这种形式的部署,并不是GR方案的主要设计目的,GR的设计与实现的时候,并不会考虑为这个场景优化。

Q:当节点出现临时问题的时候,节点是否会被自动地踢出集群?

看具体情况。如果是连接问题并且很快恢复了连接,失败检测没有发现到这个问题的话,节点并不会被踢出集群。但如果是一个足够长时间的中断,失败检测发现到的话,这个节点就会被集群踢出。一旦一个节点被踢出集群,需要DBA介入把这个节点重新加回集群。也就是说,这个恢复过程,需要DBA手工或者通过脚本操作来执行。

Q:什么情况下,节点会被踢出集群?

如果节点没有再出现对其他节点的通讯,其他节点会在自己的集群配置中自动踢出这个节点,一般出现于节点奔溃或者网络中断的时候。失败检测发生于一个指定的超时限制触发后,确认情况后,节点会重新生成一个没有失败节点的集群列表。

Q:如果一个节点出现数据延迟的话,会发生什么?

目前的情况下,集群并不处理数据库延迟的问题。DBA需要自己发现,并处理或者修复,乃至从集群中下线掉出现数据延迟的节点。当然,如果延迟过大,触发流量控制的机制,整个集群会变得很慢。流量控制机制是一个可以修改的配置,用户可以按照自己的需求配置。

Q:MySQL Group Replication是否依赖心跳或者超市机制检测失败?

的确有一个失败发现的超时,当一个节点没有任何响应之后,其他节点会自动发现这个问题,并重新构建集群列表。

Q:是否有一个特殊的节点来控制集群的成员变更?

没有这么一个节点,成员的变更都是每个成员自己发起的。每个节点都需要确认失败节点确实已经失败。之后每个成员自己会重新构建 集群列表,不需要人工参与。

关于GR的更多经典文档:

MySQL Group Replication 学习笔记

从主从复制到Group Replication

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-12-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JAVA高级架构

大型高并发与高可用的三层缓存架构总结

对于高并发架构,毫无疑问缓存是最重要的一环,对于大量的高并发,可以采用三层缓存架构来实现,nginx+redis+ehcache nginx ? 对于中间件ng...

4097
来自专栏大数据和云计算技术

MPP DB技术分类

随着数据量的增大,传统数据库如Oracle、MySQL、PostgreSQL等单实例模式将无法支撑大量数据的处理,数据仓库采用分布式技术成为自然的选择。 6.2...

3246
来自专栏IT技术精选文摘

带着问题学习分布式系统之中心化复制集

假若我说有三个节点(计算机)要维护同一分数据,如果你对分布式系统并不了解,那么你可能会有什么问题呢,我想可能有两个最基本的问题:   为什么同一份数据要保存多...

1889
来自专栏Java技术栈

史上最全Redis面试题及答案。

花了大量时间 整理了这套Redis面试题 首发50题,绝无仅有 从入门到精通 从基础,高级知识点 再到集群,运维,方案… 弄明白了这些题 可以说可以成为面霸了 ...

5157
来自专栏携程技术中心

干货 | 携程第四代架构探秘之运维基础架构升级(上)

作者简介 本文由携程技术中心框架研发部吴其敏、王兴朝,技术保障中心高峻、王潇俊、陈劼联合撰写。 作为国内最大的OTA公司,携程为数以亿计的海内外用户提供优质的旅...

32510
来自专栏美团技术团队

【沙龙干货】RDS平台介绍

今天我就给大家讲一下我们这边做的数据库运维的自动化平台,他是怎么样子的。首先我会给大家简单介绍一下我们做平台的背景,以及平台的一些技术架构,以及针对我们DBA和...

3864
来自专栏芋道源码1024

一个简单的分布式事务系统的实现(订单系统)

背景:公司最早的一个版本的订单管理,是通过PHP+mysql的方案去实现的,这样会有什么问题呢,假设如果放到一个实例里面,全部用一个单机事务去解决...

662
来自专栏DT乱“码”

原 如何保障数据库的高可用

1842
来自专栏企鹅号快讯

浅谈MySQL集群高可用架构

前言 高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言,可能包含很多模块,比如前端应用,缓存,数据库,搜索,消...

4369
来自专栏乐沙弥的世界

Percona XtraDB Cluster集群节点重启及故障转移

要重新启动集群节点,请关闭MySQL并重新启动它。该节点将离开集群(并且法定人数的总计数应该减少)。发布命令 systemctl restart mysql

592

扫码关注云+社区