MySQL Group Replication 学习笔记—group replication 小结

group replication 小结

group replication作为mysql官方,在5.7版本阶段开发的,innodb的分布式数据库架构,从发布开始就有很多关注,下文是我对目前为止的材料以及实验的一些总结。

主要资料来源是官方blog:http://mysqlhighavailability.com/

group replication架构

group replication(后文简称GR)实现的分布式数据库架构,底层的分布式基础是Paxos(出于行文限制,此处不单独交代Paxos)。通过Paxos来保证分布式数据库系统中,事务的提交顺序。

每次一个事务在一个节点提交的时候,就会发送所修改的数据到所有节点,检查期间是否有修改冲突(比如修改了别的节点已经修改并提交成功的事务的数据),如果发现冲突,本事务回滚。如果没有冲突,则可以直接提交成功。

对于非执行事务的远程节点,如果事务判断为执行成功,远程发送过来的数据,会被保存在本地的一个relay log里面(注意,与常规主从同步使用的relay log不是同一组),之后由从库的applier线程采用正常主从同步(目前已经支持LOGICAL_CLOCK并行执行)的方式执行掉对应的relay log。

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

使用建议

根据目前的状况看,GR使用的时候,应该做到以下几点以对性能优化以及减少分布式冲突。

节点分区

虽然是分布式,但并非采用纯粹的随机或者轮询来对节点访问,而是采用一些分区算法,保证指定的主键必定发生指定的实例上。

这点主要目的是避免出现事务在分布式系统中的冲突,导致不可控的事务回滚。

建议的分区算法是一致性哈希,方便节点的添加删除,以及负载均衡。

控制单次事务操作数据量

即控制事务所涉及修改(增,删,改)的数据,主要原因有两点:

一是,多节点之间的冲突检验需要传输相关的数据,如果单次事务量过大,会导致单次事务的检查时间增长,由于分布式事务的全局序列性,单个慢事务会导致全局的低速。

二是,由于最终多节点的同步,还是通过每个节点自己的relay线程来执行的,如果有大事务,会导致relay线程执行不到后面的事务,导致事务延迟,并导致可能会产生的分布式事务回滚。

周边功能介绍

主要组件简介

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

失败节点检测

只有认为无法连接的节点才会从集群中自动踢走。

机制如下:

不可用本身的发觉,是依赖消息通讯的超时决定的。即如果节点对另外的节点的消息发送超时,则认为远程节点不可用。

对于正常节点,如果认为一个其他节点不可用了,首先会标记为不可用,之后与其他节点沟通,如果确认这个节点确实其他节点都认为不可用,则实际设置为不可用节点。

如果一个节点发现自生连接不到其他所有的实例(认为其他节点全部死亡),则这个节点本身之后的事务执行,就不会采用分布式算法而是退回传统的单节点事务模式。

另外,如果同时失败节点数过多(超过一半),为了避免脑裂,分布式算法会拒绝运行,需要人工介入恢复,这也是需要注意的一点。

节点状态

  • ONLINE 节点状态正常,可以正常执行事务
  • RECOVERING 正在接收种子节点的日志
  • OFFLINE 节点之前注册了,但并不属于当前集群(可能节点已经失败)
  • ERROR 恢复阶段,阶段1或者阶段2失败
  • UNREACHABLE 节点不可达,一般出现在通讯超时的情况

失败恢复

这里说的,主要把一个节点,加入到已有集群的过程,而非单实例的崩溃恢复。

  1. 阶段1

第一阶段,新实例选择集群中的一个实例作为种子实例,这个种子实例会发送所有新实例到加入集群为止缺失的日志数据到新实例,这个的执行,是通过简单的主从同步日志的方式做的。

执行阶段1的期间,新实例还会一直持续接收当前正在活跃(实例加入集群后)的事务的日志,补全从种子实例没有传输的增量日志。

当种子实例传输日志完成之后,第一阶段就完毕了。

这一阶段,如果种子实例出现问题崩溃或者失败了,新实例会自动选取实例里面别的实例替代。

  1. 阶段2

这一阶段,新实例合并之前的活跃事务到当前数据库,当残余的事务量接近0(新事务一直在别的实例发生,只能非常接近0而很难完全追上)的时候,实例在集群中的状态,就会被修改为ONLINE了。

流量控制

mysql的GR,全局所有的实例都拥有所有的数据,也实际上需要运行所有的写入流量,如果有某一个实例相对较慢,如果时间持续下去,这个节点可能出现延迟,极端情况下,可能越追越远。

流量控制试图做到的事情是,保障整个集群节点之间,最快的节点和最慢的节点之间的事务差距不要太大。

实际需要控制的,有两个队列,一个是事务提交时候的冲突检查队列,一个是事务实际执行的relay日志队列。

DDL执行

DDL先天上并不支持事务化,也就是多节点执行的时候,如果有几个节点失败,并不会导致已经执行成功的节点回滚DDL,对于DDL的执行结果需要单独验证,以避免多节点表不一致。

IP白名单

这个主要是安全方面的考虑,之允许指定来源的ip作为复制节点与集群通讯。

限制

一些杂七杂八的限制。

  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. 外键的级联约束操作目前的实现并不完全支持,不推荐使用。

几个名词

Donor:用于节点恢复时候,传输历史binlog的节点。
Group Configuration:集群里已经配置的实例列表。
Group Membership Service:维护一致性view变更的服务,作用于节点的新增,退出,以及当前视图的维护工作。
Joiner:将要加入到集群但状态尚未恢复到ONLINE的新节点。
Seed:负责触发新节点加入集群动作的实例。

View:当前集群活跃实例的列表。

时间: 2024-07-28 15:38:34

MySQL Group Replication 学习笔记—group replication 小结的相关文章

mysql数据库基本操作学习笔记(1/2)

以下以数据库"ceshi"为例 1.连接数据库  代码如下 复制代码 mysql -u username -p password 2.创建/删除数据库  代码如下 复制代码 创建:create database ceshi; 删除:drop database ceshi; 3.创建/删除数据表 创建:  代码如下 复制代码 create table students (sid int(10) auto_increment primary key,name varchar(255),co

MySQL Group Replication 学习笔记

作者简介 刘伟  云和开创高级顾问 题记:group replication作为mysql官方,在5.7版本阶段开发的,innodb的分布式数据库架构,从发布开始就有很多关注,下文是我对目前为止的材料以及实验的一些总结. 主要资料来源是官方blog:http://mysqlhighavailability.com/ group replication架构 group replication(后文简称GR)实现的分布式数据库架构,底层的分布式基础是Paxos(出于行文限制,此处不单独交代Paxos

MYSQL的select 学习笔记_Mysql

记录一些select的技巧: 1.select语句可以用回车分隔 $sql="select * from article where id=1" 和 $sql="select * from article      where id=1",都可以得到正确的结果,但有时分开写或许能更明了一点,特别是当sql语句比较长时 2.批量查询数据 可以用in来实现 $sql="select * from article where id in(1,3,5)"

mysql性能优化学习笔记-参数介绍及优化建议

MySQL服务器参数介绍 mysql参数介绍(客户端中执行),尽量只修改session级别的参数. 全局参数(新连接的session才会生效,原有已经连接的session不生效) set global 参数名=参数值; set @@global.参数名 :=参数值; 会话参数 set [session] 参数名=参数值; set @@session.参数名 :=参数值; 内存配置相关参数 确定可以使用的内存的上限 确定mysql每个连接使用的内存 sort_buffer_size:需要注意,每个

Mysql源码学习笔记 偷窥线程_Mysql

感觉代码有些凌乱,注释代码都写的比较随意,好像没有什么统一的规范,不同的文件中代码风格也有差异,可能Mysql经过了很多牛人的手之后,集众牛人之长吧.也可能是我见识比较浅薄,适应了自己的代码风格,井底之蛙了,总之还是怀着敬畏的心情开始咱的源码之旅吧.本人菜鸟,大神轻拍. Mysql可以启动起来了,应该怎么学习呢?总不能从main开始一步一步的看吧,Mysql作为比较底层的大型软件,涉及到数据库实现的方方面面,没有厚实的数据库理论基础和对Mysql各个模块相当的熟悉,从main开始势必会把自己引入

mysql数据库入门学习笔记(1/2)

数据库一直没怎么重视,前段时间看了看mysql的基础知识,不看不知道,一看吓一跳,很多基础都竟然不知道,一直傻傻的用一些简单的.笨笨的方法,看了之后原来竟是如此如此,生活如此多娇,以前看不懂的,现在也懂点了,以前看到就头晕的,现在不晕了,发现一个奇怪的现象,应该很多人都有吧,当学一种知识的时候,而当时确实又是学不会.学不好的时候,随着时间的慢慢推移,再回过头来看的时候,发现比以前容易接受得多了--难怪这么多人到快挂的时候才后悔,不扯这么多了,把记录的笔记分享出来,方便日后查悦. 一.data数据

mysql 存储过程语法学习笔记

今天又把mysql存储过程学习了下,大家先看以下代码: 对语法不懂的朋友,可以详细看下语法结构.  代码如下 复制代码 CREATE PROCEDURE and CREATE FUNCTION Syntax CREATE     [DEFINER = { user | CURRENT_USER }]     PROCEDURE sp_name ([proc_parameter[,...]])     [characteristic ...] routine_body CREATE     [DE

mysql中子查询学习笔记

子查询最常用于SELECT-SQL命令的WHERE子句中. 子查询是一个 SELECT 语句,它嵌套在一个 SELECT.SELECT...INTO 语句.INSERT...INTO 语句.DELETE 语句.或 UPDATE 语句或嵌套在另一子查询中 子查询可以写在WHERE子句.HAVING子句.FROM子句中. 子查询分为多行子查询和单行子查询. 如果能够保证返回的行数小于等于1行的,则是单行子查询. 使用单行比较操作符:=.>.>=.<.<=.<>. 否则是多行

MySQL定时器EVENT学习笔记

 本文为大家介绍下MySQL定时器EVENT,要使定时起作用 MySQL的常量GLOBAL event_scheduler必须为on或者是1,感兴趣的朋友可以了解下 要使定时起作用 MySQL的常量GLOBAL event_scheduler必须为on或者是1    -- 查看是否开启定时器  SHOW VARIABLES LIKE '%sche%';    -- 开启定时器 0:off 1:on  SET GLOBAL event_scheduler = 1;    -- 创建事件  --每隔