PolarDB for PostgreSQL 开源必读手册-共享存储原理与实践(上)

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: PolarDB for PostgreSQL 开源必读手册-

 

一、 整体介绍

 

image.png

 

传统RDS架构在高可用的实现上采用了主备复制的模式,通过Binlog逻辑复制保证高可用。该架构存在以下几个问题:

 

增加计算节点需要同步扩容存储,导致存储成本随着节点增加而上升。

扩展只读节点较麻烦,需要进行数据重建。在数据量较大的情况下,数据重建耗时较久,可能会影响HA的耗时。

 

image.png

 

不同于传统的主备复制,PolarDB采用共享存储架构,存储和计算分离,中间通过PolarFS分布式的文件系统和存储进行共享数据。

 

RW负责数据写入,主要流程为:RW调用文件系统的API,文件系统经过内部处理将数据写入到共享存储,数据的可靠性依赖于共享存储的多副本机制。因此在DB层面,无需关心多份数据的写入。因为天然存在多副本的机制,对于DB而言,只需写一份数据在共享存储。

 

共享存储中,所有节点可共享同一份数据,PolarFS分布式文件系统天然解决了一写多读场景下的数据一致性问题。该架构下存储和计算节点分离,计算节点的扩容和存储节点的扩容互相不耦合,均可单独进行扩容。并且因为共享一份数据,新增RO节点时,无需再进行数据重建,可以秒级拉起RO节点,存储层面也可独立扩容,无需扩容计算节点。

 

image.png

 

PolarFS文件系统是专门为DB设计的用户态文件系统,并且基于共享存储支持了一写多读的实现,向上提供兼容posix的接口。

 

写节点的数据写入流程如下:调用PolarFS创建目录,PolarFS将数据写入到共享存储。由于采用了共享存储的机制,数据已经存在于存储内,但是因为PolarFS层面本身也有文件系统的元数据,需要在RO节点上通过日志同步的方式进行感知。

 

以上设计的好处在于PolarFS提供posix兼容,DB无需再大刀阔斧地改造代码,可以以较小的代价实现分布式架构,并且天然地在共享存储架构下实现了高可用。比如新增RO或HA的场景下,相较主备复制,它无需进行数据拷贝,RTO可达到分钟级甚至秒级。

 

image.png

 

PolarFS和常见的文件系统类似,主要有以下几个元数据的概念。

 

Direntry:记录文件或目录的名字。

Inode:描述文件或目录的基本属性,比如inode类型、文件长度、atime/mtime/ctime等。

Blktag:描述该block所属的文件以及在文件中的位置,每个block都拥有一个对应的blktag。

 

比如上图,创建gcc文件并进行写入时,需要为其分配数据块空间,每个数据块默认大小为4M,需要分配大于4M的空间时,将多个block进行连接,达到索引链接的目的。

 

文件系统的目录输入采用了典型的树状结构。

 

image.png

 

文件系统中需要进行MakeFS的操作,目的为对文件系统的空间进行划分,将底层的共享存储块设备进行管理。

 

假设是40G的存储设备,PolarFS将按照实际的chunk对空间进行划分,划分出4个chunk的空间。每个chunk内部又划分了大小为4M的多个block。每个chunk的第0个block将作为superblock,用于记录文件系统的元数据信息,多为blktag、direntry以及inode。每一个4兆的superblock最多可以存储2048个direntry和inode,意味着每个chunk下可以创建2048个文件或目录。

 

除了superblock之外的所有的datablock用于存放文件的数据,共有2560个。blktag元数据会负责管理datablock,映射到datablock。

 

使用PolarFS文件系统时,首先会执行格式化,主要目的是将元数据在superblock内进行格式。

 

image.png

 

日志是文件系统中很重要的组成。文件系统对文件的修改往往涉及多个不同类型的元数据修改,如果修改不能原子性完成,则会造成数据的不一致或损坏。

 

PolarFS的日志除了保证事务提交的完整性,还有一个关键用途为通过一写多读同步数据。

 

文件系统内部有很多元数据需要进行管理,当RW节点对内部的元数据进行修改之后,如果要保证一致性,RO节点上也需要对元数据进行同样的修改,才能保证一致性。该能力通过Journal的设计实现。

 

Journal文件是固定大小的空间,其中head lsn为当前事务提交到的最新位点。因为日志是循环覆盖写的过程,如果日志提交后空间不够,需要做checkpoint操作,将日志trim到磁盘上,变更也将反映到磁盘的共享存储上。checkpoint操作可将位点不停地推进,将块空间进行释放,用于提交新的log。

 

RW提交元数据之后,RO要访问文件时,首先会读取最新位点。同时,RO内部本身会维护已有的事务位点,然后判断最新位点与已有事务位点的差距,比如最新位点为10,已有位点为5,则意味着中间有5个事务尚未同步。RO会将这5个数据进行同步,并进行内存回放。同步完以后,将RO本身的已有事务位点更新至10。

 

接下篇:https://developer.aliyun.com/article/1223072?groupCode=polardbforpg

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
12天前
|
JSON 关系型数据库 PostgreSQL
PostgreSQL 9种索引的原理和应用场景
PostgreSQL 支持九种主要索引类型,包括 B-Tree、Hash、GiST、SP-GiST、GIN、BRIN、Bitmap、Partial 和 Unique 索引。每种索引适用于不同场景,如 B-Tree 适合范围查询和排序,Hash 仅用于等值查询,GiST 支持全文搜索和几何数据查询,GIN 适用于多值列和 JSON 数据,BRIN 适合非常大的表,Bitmap 适用于低基数列,Partial 只对部分数据创建索引,Unique 确保列值唯一。
|
关系型数据库 数据管理 Go
《PostgreSQL数据分区:原理与实战》
《PostgreSQL数据分区:原理与实战》
225 0
|
9月前
|
缓存 运维 关系型数据库
PostgreSQL技术大讲堂 - 第43讲:流复制原理
PostgreSQL技术大讲堂 - 第43讲:流复制原理
307 2
|
存储 关系型数据库 Go
《深入PostgreSQL的存储引擎:原理与性能》
《深入PostgreSQL的存储引擎:原理与性能》
795 0
|
存储 关系型数据库 数据库
深入理解 PostgreSQL 的架构和内部工作原理
深入理解 PostgreSQL 的架构和内部工作原理
713 0
|
Cloud Native 关系型数据库 分布式数据库
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——数据多副本
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——数据多副本自制脑图
269 2
|
存储 Cloud Native 关系型数据库
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——共享分布式存储
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——共享分布式存储自制脑图
264 2
|
存储 关系型数据库 数据库
PostgreSQL复制原理及高可用集群
文章来自: 朱贤文 | 成都文武信息技术有限公司 分析
358 1
|
Cloud Native 关系型数据库 分布式数据库
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——高速链路互联
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——高速链路互联自制脑图
237 1
|
Cloud Native 关系型数据库 分布式数据库
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——读写分离
阿里云最新产品手册——阿里云核心产品——云原生关系型数据库PolarDB——读写分离自制脑图
89 1

热门文章

最新文章

相关产品

  • 云原生数据库 PolarDB