MySQL · 引擎特性 · Group Replication内核解析之二

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

背景

前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。

无缝连接的回调机制

Group Replication是通过MySQL的插件方式实现的,基本上不影响MySQL的原有事务处理过程,只是在流程中选择性的插入一些Group Replication的特殊处理方法,为了尽可能减少对原有代码的影响,采用了回调函数的机制来实现对Group Replication的支持。 其中最重要的两个回调函数集如下所示:

  • 节点状态相关的回调函数集 Server_state_observer server_state_observer = { sizeof(Server_state_observer),
  • group_replication_before_handle_connection, //client连接到服务器之前 group_replication_before_recovery, //故障恢复之前 group_replication_after_engine_recovery, //引擎恢复之后 group_replication_after_recovery, //故障恢复之后 group_replication_before_server_shutdown, //server关闭之前 group_replication_after_server_shutdown, //server关闭之后 };
  • 事务处理相关的回调函数集 Trans_observer trans_observer = { sizeof(Trans_observer), group_replication_trans_before_dml, //DML语句执行之前,条件检查 group_replication_trans_before_commit, //事务提交之前 ,节点间事务同步 group_replication_trans_before_rollback, //事务回滚之后 group_replication_trans_after_commit, //事务提交之后 group_replication_trans_after_rollback, //事务回滚之后 }; 其中最重要的回调函数是
  • group_replication_trans_before_dml:用于执行条件检查,判断是否符合Group Replication的限制条件。
    group_replication_trans_before_commit:在binlog已经写入cache,准备提交之前通过XCOM组件进行事务的节点间同步。

XCOM消息传递机制
XCOM是一个基于paxos协议的分布式同步组件,Group Replication通过它将一个节点上的事务(事务采用binlog来表示),传递到整个分布式系统中的多数节点,保证所有节点最终都会收到此事务,并且不改变事务的执行顺序。 Server在事务提交之前,将事务的binlog打包,并添加此事务执行过程中产生的writeset及基于group replication的全局GTID。然后将其发送给本机的XCOM线程。 XCOM组件内部有一个任务Task线程,主线程通过Task调度队列来调度执行Task,每个Task任务可认为是一个协程,重要的Task有;

tcp_server 监听xcom端口,当有新连接时为其创建acceptor_learner_task任务

  • tcp_reaper_task 关闭长时间未使用的连接
  • acceptor_learner_task 此任务是XCOM的核心任务,实现基于paxos协议的消息流转过程,并最终决定accept还是deny此消息。
    proposer_task 从server的消息请求队列中读取一条消息,封装为paxos的proposal消息,发送给其它节点,尝试此消息被paxos系统accept。每个节点可以有多个proposer_task,XCOM并不保证多个proposer_task以server发出同步消息的顺序来发送proposal消息。当一个消息被accepted后,通过learn消息通知到每个节点,成为learned消息。
  • executor_task 监听learned消息,若此消息尚未被应用,则通知server应用此消息。
  • detector_task 周期性的检测与其它节点间的连接可用性。若有连接不可用,通知server。
  • alive_task 产生心跳消息。 消息被acceptor的过程,如下图所示:
    picture_name

1


1) 源节点的proposal_task从server的消息队列中提取一个消息,若是3phase,封装为prepare消息,开始acceptor的阶段一,将prepare消息发送给的所有acceptor节点;若是2phase,则封装为proposal消息,将proposal消息发送给所有acceptor节点,此时会跳到阶段二;

2) acceptor节点的acceptor_learner_task收到prepare消息后,判断是否可以阶段一的accept,然后返回ACK;

3) 源节点的acceptor_learner_task收到ACK后,更新收到ACK的节点位图,若已经收到多数acceptor的ACK后,进入阶段二,向所有acceptor节点发送proposal消息;

4) acceptor节点的acceptor_learner_task收到proposal消息后,判断是否可以阶段二的accept,然后返回ACK;

5) 源节点的acceptor_learner_task收到ACK后,更新收到ACK的节点位图,若已经收到多数acceptor的ACK后,说明此消息已经被paxos系统accept,然后将此消息通知所有节点,向所有节点发出learn消息;

6) 所有节点的acceptor_learner_task收到learn消息后,将此消息加入到当前节点的learned消息中。

7) 每个节点的executor_task检测本节点是否有新的learned消息,若有则将其通知server层,进行后续处理。

节点间事务的同步
在Group Replication中,若用户在一个节点执行一条SQL,如一条Insert语句,在提交之前已经生成此语句的binlog,并将其写入cache,此时需要通过XCOM来进行节点的事务同步,将此事务同步到多数节点,并判断此事务与其它节点的事务之间是否存在冲突,若存在冲突此事务是否需要回滚等。 下图是一个简单的SQL语句导致的消息传递过程。

2


当节点收到Notification消息后,将其加入incomingQ队列中,然后applier thread读取incomingQ队列中的消息,依次执行event事件的处理过程。对于一个insert语句来说,它的event事件由以下几部分组成:
  • Transaction_context_log_event
  • Gtid_log_event
  • Query_log_event

每个event会依次进入event handler pipeline执行相应的处理,如下图所示:

3

总结

MySQL Group Replication在提交事务之前通过XCOM来进行节点间事务的同步,保证事务提交前,多数节点上已经保存此事务相关的binlog event,从而保证节点间事务的一致性。 为降低MySQL与XCOM代码的耦合性,采用消息通知、回调函数等机制有效的对不同模块进行隔离,了解这些机制有助于我们更好的理解Group Replication的原理和代码。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
18小时前
|
SQL Kubernetes 关系型数据库
实时计算 Flink版产品使用合集之怎么解析 MySQL DDL 语句
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
15 2
|
2天前
|
负载均衡 关系型数据库 MySQL
MySQL读写分离技术深度解析
在高并发、大数据量的互联网应用环境中,数据库作为数据存储的核心组件,其性能直接影响着整个系统的运行效率。MySQL作为最常用的开源关系型数据库之一,虽然功能强大,但在处理大量并发读写请求时,单点服务器的性能瓶颈逐渐显现。为了解决这一问题,MySQL读写分离技术应运而生,成为提升数据库性能、实现负载均衡的有效手段。
|
2天前
|
API 调度
xenomai内核解析--双核系统调用(三)--如何为xenomai添加一个系统调用
本文介绍了如何在Xenomai中添加自定义系统调用`get_timer_hits()`,该调用用于获取CPU定时器中断次数。首先,在`syscall.h`中定义127号系统调用,并在`clock.h`和`clock.c`中声明和实现该函数。接着,更新libcobalt库以包含新接口。最后,提供了一个示例应用,演示如何在实时任务中使用此系统调用。编译内核和库后,运行示例程序显示定时器中断次数,体现了Xenomai的tickless特性。
17 1
|
2天前
|
Linux 编译器 调度
xenomai内核解析--双核系统调用(二)--应用如何区分xenomai/linux系统调用或服务
本文介绍了如何将POSIX应用程序编译为在Xenomai实时内核上运行的程序。
27 1
xenomai内核解析--双核系统调用(二)--应用如何区分xenomai/linux系统调用或服务
|
2天前
|
存储 Linux API
xenomai内核解析--双核系统调用(一)
本文介绍了Xenomai内核系统调用的实现,探讨了在Linux内核与Xenomai实时内核共存时,系统调用如何区分和交互。系统调用是用户空间与内核空间通信的关键,它提供了硬件抽象、系统稳定性、安全性和可移植性。在32位系统中,通过`int 0x80`指令触发,而在64位系统中,使用`syscall`指令。Xenomai通过I-pipe拦截系统调用,区分实时与非实时任务,并通过`cobalt_syscalls`表执行相应操作。文章还详细解析了系统调用表的生成和权限控制机制。
29 1
xenomai内核解析--双核系统调用(一)
|
2天前
|
消息中间件 调度 数据安全/隐私保护
xenomai内核解析--任务同步互斥机制(一)--优先级倒置
本文是关于Xenomai实时操作系统中资源管理和优先级倒置问题的概述。Xenomai使用`xnobject`和`xnregistry`管理任务间的同步互斥资源,如信号量、互斥锁等。资源管理涉及访问控制和资源保存,确保共享资源的正确调度。文章还介绍了优先级倒置现象,即高优先级任务因低优先级任务持有资源而被阻塞。为解决此问题,Xenomai采用了优先级继承策略,临时提升低优先级任务的优先级,以防止持续的优先级反转。文章后续将深入分析`xnsynch`模块和优先级倒置解决方案。
23 1
xenomai内核解析--任务同步互斥机制(一)--优先级倒置
|
2天前
|
机器学习/深度学习 算法 Linux
xenomai内核解析--实时内存管理--xnheap
Xenomai是一个实时操作系统(RTOS)层,用于Linux,旨在提供确定性的任务调度和服务。其内存管理机制包括一个名为xnheap的内存池,确保内存分配和释放的时间确定性,以满足硬实时系统的严格需求。
25 0
xenomai内核解析--实时内存管理--xnheap
|
2天前
|
Linux 测试技术 API
xenomai内核解析之xenomai初探
本文是关于Xenomai实时操作系统的初探,Xenomai是一个实时性增强的Linux系统,它通过实时内核和用户空间库提供硬实时性能。Xenomai 3主要由实时内核Cobalt、实时驱动模型RTDM、用户空间库libcobalt等组成,支持两种构建实时系统的方式:Cobalt和Mercury。Cobalt在内核空间与标准Linux内核并存,通过I-Pipe处理中断,确保实时任务的执行。Mercury则是通过修改Linux内核实现。
19 0
xenomai内核解析之xenomai初探
|
2天前
|
存储 消息中间件 Linux
xenomai内核解析--实时IPC概述
本文介绍了在Xenomai实时内核下,实时任务与非实时任务如何进行通讯
14 0
xenomai内核解析--实时IPC概述
|
2天前
|
关系型数据库 MySQL 数据库
docker MySQL删除数据库时的错误(errno: 39)
docker MySQL删除数据库时的错误(errno: 39)
23 0

推荐镜像

更多