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 条评论
登录 后参与评论

相关文章

来自专栏贾老师の博客

Lua 游戏开发学习

3352
来自专栏漏斗社区

安全运维中基线检查的自动化之ansible工具巧用

前几周斗哥分享了基线检查获取数据的脚本,但是在面对上百台的服务器,每台服务器上都跑一遍脚本那工作量可想而知,而且都是重复性的操作,于是斗哥思考能不能找到一种方法...

2783
来自专栏木子墨的前端日常

本机未装Oracle数据库时Navicat for Oracle 报错:Cannot create oci environment 原因分析及解决方案

因为要更新数据库加个表,远程桌面又无法连接。。。所以就远程到另外一台电脑,然后用navicat通过内网修改目标数据库。

1303
来自专栏互联网杂技

为何webpack风靡全球?三大主流模块打包工具对比

前端的模块系统经历了长久的演变,对应的模块打包方案也几经变迁。从最初简单的文件合并,到AMD 的模块具名化并合并,再到browserify将CommonJS 模...

3948
来自专栏owent

atframework的etcd模块化重构

最近在抽时间整理之气的游戏服务器框架和解决方案里atsf4g-co,现在的架构是使用etcd的是atproxy。简单得说就是服务集群是分组的,每个分组有分组代理...

1292
来自专栏编程

在Linux中,一切都是文件

每个人都知道一个文件是什么...这就是你使用的“照片”,“文档”或“音乐”。程序是由文件组成的,实际上,整个Linux操作系统只是一个文件集合...但是,现在是...

21610
来自专栏生信技能树

用wget下载需要用户名和密码认证的网站或者ftp服务器文件

虽然我以前经常写爬虫,但毕竟是代码活,复用性非常低,每次得耗十几分钟解析网页并且写好代码。而熟悉linux的朋友都应该了解wget这个神器,有了url之后一行命...

2.2K8
来自专栏腾讯大讲堂的专栏

zookeeper 运营经验分享

Zookeeper作为TDBank系统的一个重要模块,我们运营它已经两年多。在使用过程中,我们也遇到了一些问题及走过很多弯路,本文主要对zookeeper运营经...

2357
来自专栏熊二哥

Linux快速入门04-扩展知识

这部分是快速学习的最后一部分知识,其中最重要的内容就是源码的打包和软件的安装的学习,由于个人的Linux学习目的就是自己能在阿里云Ubuntu上搭建一个简单的n...

2695
来自专栏腾讯大数据的专栏

zookeeper 运营经验分享

Zookeeper作为TDBank系统的一个重要模块,我们运营它已经两年多。在使用过程中,我们也遇到了一些问题及走过很多弯路,本文主要对zookeeper运营经...

2869

扫码关注云+社区

领取腾讯云代金券