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

相关文章

来自专栏CSDN技术头条

Redis错误配置详解

Redis提供了许多提高和维护高效内存数据库使用的工具。在无需额外配置应用层的前提下,Redis独特的数据类型、指令和命令调优就可以满足应用的需求,但是错误的配...

18810
来自专栏智能大石头

如何使用网络库实现应用级消息收发

网络客户端ISocketClient和网络会话ISocketSession都继承了ISocketRemoteISocketRemote表示远程通信,核心就是收发...

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

从构建分布式秒杀系统聊聊分布式锁

最近懒成一坨屎,学不动系列一波接一波,大多还都是底层原理相关的。上周末抽时间重读了周志明大湿的 JVM 高效并发部分,每读一遍都有不同的感悟。路漫漫,借此,把前...

683
来自专栏智能大石头

如何使用网络库实现应用级消息收发

网络客户端ISocketClient和网络会话ISocketSession都继承了ISocketRemoteISocketRemote表示远程通信,核心就是收发...

440
来自专栏美团技术团队

Java NIO浅析

NIO(Non-blocking I/O,在Java领域,也称为New I/O),是一种同步非阻塞的I/O模型,也是I/O多路复用的基础,已经被越来越多地应用到...

3599
来自专栏JAVA高级架构

Redis面试题及分布式集群

1111
来自专栏乐沙弥的世界

DRBD原理及特性概述

Distributed Replicated Block Device(DRBD)是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。其核...

411
来自专栏无题

软负载中心与集中配置管理

软负载中心两个最基础的职责 聚合地址信息 生命周期感知->需要能对服务的上下线自动感知,并且根据这个变化去更新服务地址数据 软负载中心两个最基础的职责 聚合...

2804
来自专栏数据和云

深入剖析 Group Replication内核的引擎特性

小编寄语 主库master与从库slave的切换不管是主动的还是被动的都需要外部干预才能进行,这与数据库内核本身是按照单机来设计的理念悉悉相关,并且数据库系统本...

3628
来自专栏Java架构师学习

日志: 分布式系统的核心日志的应用

最近这段时间一直在研究消息队列、文件系统、数据库等,慢慢的发现他们都有一个核心组件:日志.有时也叫write-ahead logs 、commit logs 或...

2757

扫描关注云+社区