首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >GR运维手册 - 第一册 苦海岸边,GR的基础知识

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

作者头像
数据和云
发布2018-03-06 17:51:12
9990
发布2018-03-06 17:51:12
举报
文章被收录于专栏:数据和云数据和云

作者简介:

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

多年一线互联网企业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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据和云 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Group Replication 程序结构
  • 在MySQL的底层,GR增加了另外的API层来实现所需要的功能。
  • MySQL Group Replication 使用 单个事务,必须只能发生在一个节点(集群内分布式事务没有意义,因为所有节点的数据都是一样的)。
  • MySQL Group Replication 目前的限制 1. 所有涉及的数据都必须发生在InnoDB存储引擎的表内。
  • MySQL Group Replication 的一些问题的回复(官方文档) Q:MySQL Group Replication最多允许几个节点?
  • MySQL Group Replication 学习笔记
  • 从主从复制到Group Replication
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档