《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(中)

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: 《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(中)

《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(上) https://developer.aliyun.com/article/1232684?groupCode=polardbforpg


一致性协议复制实现


(一)基本原理


接下来介绍一致性协议复制的具体实现。


image.png


首先我们看一下PolarDB for PG一致性协议复制的基本原理,主要包含两方面,第一方面是通过原生的异步流复制来传输WAL日志,另一方面是哪些日志在多数派上已经同步成功,这是由Leader节点上通过X-Paxos协议来确定的。对X-Paxos来说,日志提交位点是以Consensus Log为载体的,然后推进Consensus Log提交位点,所以我们会针对每一段WAL日志生成一个相应的Consensus Log etnry,然后Consensus Log etnry中记录的是这段WAL日志的一个结束LSN。


如上图的例子,比如在Leader节点上,我们已经有三段日志,有了相应的一个Consensus Log etnry,第一段LSN是从100-200,第二段是从200-300,第三段是从300-450,然后生成的Consensus Log Index分别是1、2和3,我们把ConsensusLog etnry和WAL日志位点首先要结合起来,然后我们又引入了持久化的依赖,就是说每个Log etnry在持久化的时候,必须要确保相应位点的WAL日志已经持久化成功。


LogIndex1要持久化之前,我们必须要确保LSN等于200之前的WAL日志都已经回刷了,这样Consensus Log的回刷位点本身跟WAL日志的回刷位点也结合起来了。


在引入了这两个机制之后,如果Consensus Log提交成功了,那么就是说Consensus Log肯定已经在多数派上持久化成功了。根据刚才的依赖,对应位点的WAL日志肯定也已经在多数派上持久化成功了。


大家可以看看下面的例子,Leader上面有三段WAL日志已经生成对应的Log etnry,然后三个Log etnry对应的WAL日志也都已经持久化了,包括Consensus Log etnry自己也都已经持久化了。那么在Follower1这个节点上,虽然Log index为3的WAL日志已经持久化成功了,但是可能由于并没有接收到Log Index为3的Consensus etnry,所以Log etnry并没有持久化成功。然后Follower2上面Log Index为3的Consensus etnry和WAL日志,因为WAL日志本身都没有持久化成功,所以Consensus Log就根本不可能持久化成功。


在根据这三个节点的现有状态,就是根据X-Paxos协议,当前Leader会发现LogIndex为2的日志在多数派节点上已经都持久化成功了,所以在Consensus Log层面的Commit Index是2,转化成LSN之后,Commit LSN也就是300,这是我们针对LSN多数派同步的基本原理。


(二)进程/线程架构


下面讲一下实现层面的几个关键点


• 独立的consensus进程提供多数派日志同步服务

• WAL日志同步采用原生流复制逻辑



image.png


首先是进程和线程的架构,PG本身是多进程的架构,而X-Paxos是多线程架构,这里面会涉及到的一些问题,就是PG的进程本身无法直接调用X-Paxos的接口,或者它无法直接访问X-Paxos内部的私有内存,所以我们最终选择以X-Paxos为基础,然后新引入了一个Consensus的服务进程。


进程内部会包含多个线程,然后其中包含了X-Paxos的多线程,对外它主要提供多数派日志提交以及相关服务。这个服务是一个常驻的进程,就是说当startup进程启动之后,在这个进程中启动。


首先介绍一下Consensus进程内部的几类线程,第一部分就是X-Paxos内部的一些线程,包括I/O线程和工作线程。I/O线程主要负责节点间的网络通信,工作线程主要负责协议的处理,比如发起选举,比如Follower节点要处理日志的Append请求,可能需要发起选举的请求,主要是跟一致性协议、算法相关的处理逻辑。


除了这些线程外,Consensus进程本身又引入了四类线程,首先是 Append Thread。刚才在原理里提到说,我们会对每一段的WAL日志生成Consensus log,这主要是由 Append Thread 来完成的。它根据当前 WAL 日志的回刷位点来生成Consensus log etnry,然后把log etnry传递给X-Paxos进行同步。


第二类线程是 Advance thread,是推进WAL日志的提交位点,它主要就是从X-Paxos中获取当前 Consensus log 的提交位点,然后把它转化成LSN位点。另外,Advance thread同时会根据Consensus协议层的一些状态变化,来驱动PG层进行状态变更。比如Consensus层发生了切除操作,那么Advance层检测到切除的动作或事件之后,它就会触发驱动Postmaster或startup进程进行一些相应的变动,这个下文会具体阐述。


第三个是Command 线程,它主要是处理一些集群变更的命令。比如Leader切换、增删节点等命令,一般来说在PG内部的处理方式是用户发生的请求一般由Server Process处理,但Server Process本身又无法直接调用X-Paxos内部的一些接口,所以我们的处理方式是Server Process把所有的管理请求放到一个共享队列里,然后由Command threads从共享队列里面拿请求来处理,处理完成之后再把执行结果放到执行队列里面去,然后返回给Server进程。


第四类是统计类的线程,这一类线程主要是处理一些状态和统计信息获取的类型图,也就是获取X-Paxos协议内部的一些状态。整个处理的逻辑跟集群变更的命令差不多,也是通过共享队列进行交互。

接下来讲一下Consensus内部的内存情况,以及它的并发控制机制。


内部内存主要分为两种,一种是X-Paxos本身分配的私有内存,这部分内存只有Consensus内部的一些线程,包括X-Paxos线程,以及刚才提到的Server Threads。Server Threads包括 Command Threads和统计的Statistics线程。


除了这一类内存之外,另外一种内存可以由X-Paxos线程,Consensus线程以及PG进程都可以访问的共享内存。这些内存主要是进行Consensus process以及 PG进程之间的一些状态交互,这类内存的访问接口必须是线程安全的。对于PG侧的一些共享内存,Consensus Process内部可能也是需要访问的,这时候我们必须要确保Consensus Process内部只有一个线程会访问这些内存,可以认为Consensus Process来访问这块内存。


第三个是Consensus Log的管理,这里能确保只有Consensus process内部的一些线程进行读写。

以上是整个进程和线程的架构。


《PolarDB for PostgreSQL源码与应用实战》——PolarDB for PostgreSQL高可用原理(下) https://developer.aliyun.com/article/1232677?groupCode=polardbforpg



相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
打赏
0
0
0
0
81
分享
相关文章
PostgreSQL 9种索引的原理和应用场景
PostgreSQL 支持九种主要索引类型,包括 B-Tree、Hash、GiST、SP-GiST、GIN、BRIN、Bitmap、Partial 和 Unique 索引。每种索引适用于不同场景,如 B-Tree 适合范围查询和排序,Hash 仅用于等值查询,GiST 支持全文搜索和几何数据查询,GIN 适用于多值列和 JSON 数据,BRIN 适合非常大的表,Bitmap 适用于低基数列,Partial 只对部分数据创建索引,Unique 确保列值唯一。
【PolarDB-X从入门到精通】 第四讲:PolarDB分布式版安装部署(源码编译部署)
本期课程将于4月11日19:00开始直播,内容包括源码编译基础知识和实践操作,课程目标是使学员掌握源码编译部署技能,为未来发展奠定基础,期待大家在课程中取得丰富的学习成果!
【PolarDB-X从入门到精通】 第四讲:PolarDB分布式版安装部署(源码编译部署)
[PolarDB实操课] 05.通过源码部署PolarDB-X标准版
本课程介绍如何通过源码部署PolarDB-X标准版,涵盖基于Paxos的MySQL三副本工作原理和技术特点。主要内容包括: 1. **Paxos三副本工作原理**:讲解Leader和Follower节点的角色及数据同步机制。 2. **技术特点**:强调高性能、数据不丢失(RPO=0)和自动HA切换。 3. **源码部署步骤**:详细演示从编译生成RPM包到启动DN节点的过程,包括配置my.cnf文件和初始化数据库。 4. **高可用体验**:通过三台机器模拟三副本集群,展示Leader选举和故障转移机制,确保数据一致性和服务可用性。
108 1
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
232 0
PolarDB实操课] 04.通过源码部署PolarDB-X企业版
本次课程由PolarDB开源架构师王江颖分享,详细介绍了通过源码部署PolarDB-X企业版的全过程。主要内容包括: 1. **编译基础** 2. **使用源码编译部署PolarDB-X企业版** 3. **演示实例**:通过阿里云ECS进行实际操作演示,从创建用户、赋予权限到最终启动并连接PolarDB-X数据库,展示了完整的部署过程。 4. **总结**
【PolarDB开源】PolarDB-X源码解读:分布式事务处理机制揭秘
【5月更文挑战第20天】PolarDB-X,PolarDB家族的一员,专注于大规模分布式事务处理,采用2PC协议保证ACID特性。源码解析揭示其通过预提交、一致性快照隔离和乐观锁优化事务性能,以及利用事务日志进行故障恢复。深入理解其事务处理机制对开发者掌握分布式数据库核心技术至关重要。随着开源社区的发展,更多优化方案将涌现,助力构建更强大的分布式数据库系统。
284 6
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
PolarDB-X源码解析:揭秘分布式事务处理
【7月更文挑战第3天】**PolarDB-X源码解析:揭秘分布式事务处理** PolarDB-X,应对大规模分布式事务挑战,基于2PC协议确保ACID特性。通过预提交和提交阶段保证原子性与一致性,使用一致性快照隔离和乐观锁减少冲突,结合故障恢复机制确保高可用。源码中的事务管理逻辑展现了优化的分布式事务处理流程,为开发者提供了洞察分布式数据库核心技术的窗口。随着开源社区的发展,更多创新实践将促进数据库技术进步。
139 3
PolarDB产品使用问题之列存索引的原理是什么
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
100 1

热门文章

最新文章

相关产品

  • 云原生数据库 PolarDB
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等