分享人：朱元(圆珠)   阿里云数据库产品事业部

正文：本文从两方面来介绍PolarDB存储原理与实践.

• PolarDB存储原理简介

• PolarDB存储实践

1、PolarDB存储原理简介

1.1PolarDB: 基于共享存储的分布式数据库

PolarDB和传统的RDS最大的区别是基于共享存储的部署方案，它们在存储侧的差异有：

成本的差异，传统的关系型数据库的复制数据量存储会double，写量也会double，日志数据分别会在不同的节点上面都写两次。共享型存储器没有这些问题，写量永远只有一次。

由于是分布式的存储，它不需要预分配，可以在存储侧独立的进行动态扩容。存储侧独立的实现，上层解耦分布式架构上常见的难点和问题，比如数据库本身不用考虑存储的可靠性了，由下面的存储成本实现它的可靠性，传统企业的副本技术EC可以去实现，企业级的快照功能可以对上层进行隔离，去提供快照备份。

1.2共享存储架构下的计算层修改：缓存同步

数据库需要做哪些修改呢？我们其实可以很简单的把它做一个抽象的划分，存储层和计算层，如果存储层使用统一共享的存储计算需要做哪些修改，由于存储已经共享了，计算层涉及的数据对象是缓存，存储层的共享不存在一致性的问题，计算层需要解决缓存同步的问题，缓存同步包括几个部分：

一是内容的同步，在a节点写入的段数据，b节点的缓存和a节点的缓存要一模一样。

二是要看到相同的内容和相同的修改顺序。a节点上依次修改了两份数据，要在b节点上看到这两份数据的修改顺序也是相同的，实际在RW先写日志再写数据的顺序，没有在RO中进行完整一致的问题。在看到日志时没有看到数据，这些都是顺序问题。

存储计算分离架构在计算层需要做的修改是缓存同步，缓存同步也包括内容一致修改和顺序一致。传统的存储数据库存储还有文件系统，它是属于内核态的，也是有缓存的，cache是数据侧的缓存，文件系统有一些源数据，文件名数据的缓存也需要同步。

1.3PolarFS: PolarDB的用户态文件系统

PolarDB使用的文件系统是PolarFS，传统的文件系统在运行内核态上去做缓存同步会出现一些问题：一是开发难度较大，二是比较难合并上游内核依赖代码的更新。最终选择了一套自研的运行在用户态高性能面向数据库的文件系统，为文件系统提供满足Linux标准的接口，能够提供mkdir、rdaddir文件夹和文件的所有接口，这是HDFS不能完整提供的，最重要的是能够支持在共享快设备上实现一写多读缓存同步。

1.4PolarFS的元数据基本结构

和传统单机文件系统一样，要有格式化的过程，把整块磁盘分解为数据扇区和原数据扇区，数据扇区用于存储平常文件读写中存储的数据，在元数据扇区会存储原数据文件系统的原数据，主要有：文件的名字、所属文件夹、文件中的块和磁盘的块之间的映射，对应到PolarFS对原数据的处理，它提供了dir存储文件名或者文件夹名，来存储文件块到磁盘块之间的映射，再提供数据结构来完成索引，例如文件夹和文件名之间的观点。

1.5PolarFS的元数据修改的提交和同步

分布式缓存的同步如何来解决呢？RW节点需要把对原数据的修改进入到Journal的日志，并且也使用类似DB的LSN的版本号的技术，可以让RO在节点上看到RW上修改的先后顺序，RO是何时做的缓存同步呢？

文件系统不像数据库有同步机制，把同步延时到RO文件系统访问API上去，也就是在RO上去做一次读文件的操作时，都会额外的去读Journal日志文件，去查看上一次回放日志后的位置是否有新日志写入。每一个RO在做API调用的时候，一定能看到在RO上RW元数据的修改。

日志本身都有顺序性，对日志内容的回放顺序也和RW上的修改顺序也是一样的。

1.6PolarFS和PolarDB的缓存同步分工

PolarFS文件系统的数据缓存在实际工作中是没有缺失的，PolarDB在开发过程中，DB和文件系统做了数据缓存和原数据缓存的分工，原数据缓存中文件名的修改、文件块的分配的操作给文件系统做，数据内容的缓存同步给DB来修改，因为DB天生自带WAL日志等功能，DB执行的缓存复制的功能也是分布式同步中必须的。同理，基于已经开源的PolarFS写一个共享存储的数据库，PolarDB可以使用日志来同步，可以使用TCP信道RW让 RO更新缓存。

在数据库中使用DirectIO是非常重要的，如果不使用DirectIO，那么在RO上面缓存的更新就通过API来读，操作系统替代了自带的缓存，缓存同步要控制在逻辑之中，我们整套RO站中必须是做分布式缓存同步的缓存。

2、PolarDB存储实践

2.1PolarFS的部署

2.1.1PolarFS的编译和安装

对于PolarFS的部署，大家可以直接从上面的链接下载源码，遵照上面的文档，准备好第三方库再进行编译，编译出运行文件系统需要的工具服务等，要格式化文件系统就已经可用了。

2.1.2PolarFS bash工具使用示例

看下系统中有哪些磁盘可用，比如有1块nvme5n1可以用的时候，可以运行mkfs的命令把磁盘格式化，格式化好后，继续用mkdir的命令操作格式化的磁盘，路径的开始和传统的Linux路径有一些区别。

命令行mkdir或者IS前面加了PFS的工具，它不能直接使用自带的二进制工具，必须在命令前加PFS开始编译生成的工具才能访问文件系统。

它是独立的文件系统没有挂载在系统的根路径上，把路径的第一部分设为要格式化的盘符，区分需要从哪一块设备上去访问PolarFS。

2.1.3 PolarDB postgresql 实际文件示例

PolarDB的表空间上的文件夹和文件，和开源社区版没有任何区别，访问看到的结果和社区也差不多是一样的。有一些，我们PolarDB在社区版上额外增加功能的额外文件夹，像logo index。在data根目录上面可以看到多出一些PG的这个logo index等文件夹，也可以通过命令去查看PolarDB数据库在文件系统存储中增加的变化。

2.1.4 PolarFS bash工具命令支持一览

PolarFS对标传统文件系统实现常用的子集，通过/h可以看到帮助手册实现的命令。

2.1.5 PolarFS 部署形态

必须要通过API的形式去访问文件系统，在PolarDB实际使用中必须要提供API的形式去数据库进行访问， PFS demo服务就是做这件事情的，启动后PolarDB就可以去访问文件系统服务了。 postgresql是主进程子进程的架构，需要主进程调用和PFSdemo服务建立共享内存的连接，folk的子进程通过文件系统的API来访问文件系统服务的共享存储。传统文件系统是通过切入内核态直接调用，这里是通过共享内存的方式转接到用户态的文件系统服务，把它共享文件夹上的共享内存文件来通讯，通信的机制不依赖于内核态的转发形式进行。

2.2.1基于光纤或以太交换网络的SAN

常见的方法是通过光纤交换网络或者以太交换网络，存储节点上的存储设备通过网络的形式虚拟化成存储单个的虚拟和设备，提供给计算层面的服务器访问。这种架构实现计算存储分离，服务存储在交换网络之外，计算层是在网络上进行访问。

2.2.2SAN on linux 部署

首先完成上网络的初始化后，在Llinux的操作系统上扫描确保网络上连通的设备能在本地发现。

2.2.3块设备注册与发现完成

可以看到设备类型第一行是b，可以看到这台主机上发现了非常多的远端存储设备，计算存储分离的rw、ro可以共同访问，刚才的操作，除了在aw主机上执行，在上面也去执行，那两台主机就可以共同去访问相同的存储了。

2.2.4管理存储访问

传统的SAN存储网络，可以把多块盘合并成一块逻辑盘，类似于read的方式同时利用多块盘的带宽提升数据的访问性能。和传统的交换式网络相比，基于固定的路由访问远端节点不同，可以配置动态的网络访问拓扑，让流量负载均衡从多条路径访问远端的存储节点，避免网络路径产生瓶颈。可以并行的使用多块存储的带宽，也可以并行的使用多台链网络和存储的带宽，以少量的计算节点利用整个网络的性能。

2.2.5存储示例

这是一个简单的示例，第一块磁盘属于一个设备， 253：21是Linux的描述符，第一部分属于驱动。第二部分是minor设备的标识符，访问设备的时候可以去配置负载均衡的策略，优先级走某些链路访问，较低的优先级去访问另一条链路。

2.2.6扩容流程

每一个事情上都包含动作和感知两个过程，首先用SAN存储厂商的存储软件，像浪潮的存储提供的软件扩容，或者多个盘合并成一个盘，这些都是扩容。其次在Linux的快设备管理上特定一块盘，比如想对这块逻辑盘进行扩容，Linux就能感知远端的存储扩容结果。因为计算和存储是分离的，计算节点上有多个节点在访问这个存储设备，就需要在每台计算主机上去执行，才能保证每台主机上都能看到远端存储扩容的结果。

这是快设备层面的感知。我们使用的是PolarFS文件系统，它提供了一些命令，可以直接使用它去感知和使用扩容的结果。首先要把扩容的结果格式化，就像第一次使用文件系统那样格式化。其次需要去感知扩容结果，也就是说在每台主机中需要在数据库中去调用特定的API感知扩容的结果，那当你的RW节点也感知到扩容后，RW就利用扩容的分空间进行数据分配，replay是远端修改的。感知是一个从下到上的过程，复制过程和缓存顺序是相反的，先从底层去完才能够避免crash的问题。传统文件系统没有这么复杂，第三步和第二步可以就合并。

2.2.7已有部分用户案例

这套方案主要是面向线下的企业用户推荐的，他们大多都有SAN存储的网络设备，方便使用已有的基础设施和软件部署，也有国家政府和企事业单位的案例，就不一一介绍了。

2.3 NBD存储的部署

2.3.1NBD的概念

NFS是基于文件系统的共享，共享本机的路径也就是文件系统中的目录或者子目录，远端修改文件可以在本地上看见和同步。快设备也类似于NFS那样通过tip网络信道进行共享，Linux也提供类似的功能。把dv磁盘映射到远端，让远端通过映射设备访问a节点写入的数据，b节点就可以直接看到。

2.3.2NBD的服务端部署

不同的操作系统是不同的，服务端只需要启动对应的NBD的服务，把准备分享的快设备描述清楚，以同步的方式去分享，避免系统有crash。

2.3.3NBD的客户端部署（一）

客户端需要在/dev上模拟本地的磁盘节点。也可以自己编译一下内核的驱动，生效后就可以在dv目录下面看到NBD设备了，根据服务端的配置把远程的设备映射到本地的NBD设备上面。

2.3.4NBD的客户端部署（二）

我们要把NBD和远程的共享磁盘进行映射，只需要把NBD对应远端的服务端口，映射到本地某一个NBD设备上面，执行成一旦成功，就可以看到本地磁盘块设备中增加的NBD磁盘设备。

2.4基于阿里云共享存储的部署

2.4.1云上共享存储（一）：Polarstore

直接在阿里云官网上购买服务，包括MySQL兼容版本、PG版本，Oracle兼容版本，云上的存储架构和基于SAN存储架构很类似，存储计算分离网络连接是把基于光纤的交换网络换成RDMA的网络机制，来做存储计算之间的高速互联以及存储网络之间高速互联，这套方法是最简洁最方便最稳定可靠的一种方案。

2.4.2云上共享存储（二）： ESSD云盘

NBD共享需要手动部署，未来会提供ESSD云盘原生共享的方案，在ECS主机上购买一块盘，在别的主机上也能配置映射这块盘，不需要自己去配置NBD的模块，一块盘多个主机也能使用这样的功能。