pg数据库数据文件111代表什么

仅供参考

所有数据库对象都有各自的oid(object identifiers),oid是一个无符号的四字节整数，相关对象的oid都存放在相关的system catalog表中，比如数据库的oid和表的oid分别存放在pg_database,pg_class表中。

1、数据库集群-Database cluster

2、数据库-Database

3、表空间-tablespace

数据库在逻辑上分成多个存储单元，称作表空间。表空间用作把逻辑上相关的结构放在一起。数据库逻辑上是由一个或多个表空间组成。

新创建的数据库默认创建下面的表空间：

1)Catalog表空间 存放系统表信息2)System表空间 存放用户数据3)Temp表空间

4、模式-Schema

自动创建的系统模式如下：

1)PG_CATALOG2)PG_LARGEOBJECT3)PG_TOAST4)PG_PARTITION

默认的用户模式PUBLIC。

5、段-segment

6、区-extent

7、块-block

8、数据库对象-Database object

1)模式对象表、索引、序列、大对象、视图、函数、存储过程、触发器、包 … …2)非模式对象用户、数据库

9、数据表-Table

10、索引-Index

11、序列-Sequence

12、视图-View

二、物理存储结构

在执行initdb的时候会初始化一个目录，通常我们都会在系统配置相关的环境变量$PGDATA来表示，初始化完成后，会再这个目录生成相关的子目录以及一些文件。在postgresql中，tablespace的概念并不同于其他关系型数据库，这里一个tablespace对应的都是一个目录。如下图就是PG的物理结构：

e3b8db31b00c2f05d483b06281f4612b.png

1、存储系统主要包括三个部分：

内存中：buffer，MemoryContext；

数据文件，临时文件；

日志文件，日志缓存。

2、文件和目录相关作用描述：

b0bf0a554cc377fae5f8de898df5e43d.png

61b64f793a40b1d2a91e97af7f7c064f.png

3、数据文件结构

3c57d6e6090ee00e4ee3dd1e4ecb3550.png

3.1、页

aefc00e308669659fe45719ea93668ea.png

将数据文件中的空间从逻辑上划分成一个个页面(数据块)。页面是数据库I/O的基本单位，即只能整页读写数据文件, 页面的大小默认是8K。

页面可以分成两种：

1)数据页面：数据页面是用来存储用户数据的。

2)控制页面：控制页面用来管理这些数据页面。

数据库共享缓存中的空间划分也是按页为基本单位, 一个页的大小与数据文件中页的大小一致, 这样便于整页读取数据文件,并放入到数据库Buffer中, 从Buffer写入数据文件也同理，保证了缓存与数据文件结构和内容上的一致性。

3.2、Block(块)

概念上基本等同于Page, 但Block更多用于说明DMS中对数据文件中Page的描述。

例如: 对文件的读写的 *** 作, 文件读写位置的定位, 数据文件空间回收等 *** 作, 单位均是以块进行。

数据块的大小在系统初始化时指定，默认是8K，可以取值4K,8K,16K,32K。

3.3、Extent(区)

把数据文件中8个连续的Page构成的空间称为一个Extent。Extent是数据库进行数据文件空间分配/释放的基本单位。每个表、索引、序列对象都是由若干个区组成。数据文件被创建后，除自动保留部分区作为控制区外，其他区全部处于未分配状态。表、索引、序列对象的所有数据都存放在Extent中，当向这些Extent中插入数据时，若该Extent的所有页面都已占满，系统就会自动在所属表空间的数据文件中寻找一个尚未分配的区，并将其状态修改为数据区。

3.4、控制页面

用于空间管理的控制页面：PFS/GAM/IAM。

用于增量备份的控制页面：DCM。

判断可见性的控制页面：VM。

预留的控制页面：BCM/SGAM。

3.5、PFS

Page Free Space,简称PFS页.

用于记录本数据文件中页面的空间使用情况。对文件中的每个页面，PFS中都有一个“字节”与之对应，该字节记录了该页面的状态。

PFS页前64bytes被预留为页头, 剩下81024-64=8128一共覆盖81288K=64MB空间.

故PFS页每隔8128个页面出现一次, 系统初始化把第一个PFS页放在数据文件的第二个页面位置,即:第1号数据页面, 由此可知,第N个PFS页的位置在8128*N+1.

ed48dc29b411c3c5ef7bc7fe817ef757.png

3.6、GAM

Global Allocation Map，简称GAM页。

功能:记录所在数据文件的Extent的分配情况，GAM页中除GAM头外,剩下空间的每一位(bit)均对应一个Extent的分配情况。若某bit位为1，则表明该bit位所关联的Extent已被分配出去,反之未被分配。

若一个GAM页面大小为8K,则除GAM头(64 bytes)外,一个GAM页面所能覆盖的文件范围是: (81024-64)8(88K),约4GB空间。此外，GAM页每隔881288个页面出现一个，系统要求第一个GAM页出现在文件的第3个页面位置(即:第2个索引位置),由此得知,第N个GAM页的出现位置是: 881288*N+2

8787a745b70fe3df6b2e0df0671574b1.png

3.7、IAM

Index Allocation Map，简称IAM页。

功能：每个IAM页只隶属于一个数据库对象(例如:表),但一个数据库对象可包含多个IAM页,由此可见IAM页与数据库对象的关系是1对1，而数据库对象与IAM页的关系是1对多.

IAM的结构与GAM页类似,除IAM头外,剩下空间的每一位(bit)均对应着一个与IAM相关的Extent。若某bit位为1，则表明该bit位所关联的Extent已被分配给该IAM,反之未被分配。若一个IAM页面大小为8K,则除IAM头(64 bytes)外,一个IAM页面所能覆盖的文件范围是: (81024-64)8(88K),约4GB空间。

但与GAM也不同之处在于:IAM的出现位置不固定,只在在创建数据库对象的时候才分配。

6bc56896143910b2e3b060025dd891eb.png

三、逻辑与物理存储关系

1、逻辑关系存在表空间；

2、表空间存在对应的数据文件中；

新创建的数据库对应的数据文件的名称:

Catalog表空间 – databasename.dbfSystem表空间 – Udatabasename.dbfTemp表空间-- Tdatabasename.dbf

前面加 “U” 前缀代表用户数据表空间，用于保存用户表的数据。

不带 U 代表 是系统表的表空间，用于保存系统表的数据。

U 前缀的数据文件代表的表空间名为PG。

不带U 的数据文件代表的表空间为 CATALOG。

四、数据库文件、表空间、其他文件之间的关系

1、关系图如下：

1e59db43b34dcdd4d6c5cb6b89b2c194.png

说明：

1)每一个数据库具有一个或多个数据文件，用户存放数据库的所有数据。

2)数据库的数据文件有以下特征：

一个数据库文件只能与一个数据库的一个表空间相连。

一个表空间可以由多个数据文件组成。

3)数据库对象与文件关系：

数据库对象放到表空间中。

表空间有多个数据文件。

表空间中有多个数据库对象。

4)数据库对象逻辑上是存储在表空间中，物理上是存储在与表空间相关联的数据文件中。

2、数据库包含的文件种类：

1)数据库文件：data/DB

数据库对象，如：数据库、表，索引，序列等对象。

2)控制文件：data/CTL

用来记录数据库集群的状态信息，如：版本信息、集群所管理的各种文件信息、检查点信息、事务状态信息等。

3)日志文件：data/REDOLOG

记录数据修改 *** 作的日志，用于系统发生故障时进行数据恢复。

4)临时文件：data/DB

存放数据库进行计算的过程中，生成的各种中间对象，如排序运算的外存归并单元。

5)参数文件：data目录下

五、Postgresql 底层存储管理方式：

Postgresql的每个数据库均存放在一个目录中，以db_oid命名，该目录中存放每个表对应的文件，文件名以该数据表对应的relfilenode_oid命名。当表中的数据量足够大，导致表文件的大小大于1GB的时候，postgresql会自动创建新的文件用于存放新插入的数据。新文件的名称为： relfilenode_iod.1, relfilenode_iod.2 等。使用该策略是为了防止在某些文件系统中，最大支持文件尺寸不能大于1GB的情形。

db_oid, relfilenode_oid可以从pg_class系统表中查询得出。

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。

1、业务流量入口的配置方式

传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。

2、容器隔离带来的监控视野问题

在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。

3、存储在 kubernetes 中，支持配置各种不同的存储。

如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。

4、高可用/备份恢复

kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复 *** 作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。

---