PG控制文件

控制文件

控制文件介绍

PostgreSQL 控制文件在$PGDATA/global目录下名为pg_control

PG控制文件pg_control里存储的数据时一个ControlFileData结构。控制文件尽量保持小于512个字节以使其适合一个典型的磁盘驱动的物理簇的大小。这会减少由于电源故障而写控制文件直接失败的可能性。但控制文件的物理大小是8K，远大于512个字节。这样做是为了控制文件格式变化时保持物理大小不变，如果正在读一个不兼容文件，以使ReadControlFile能传递一个合适的错误版本控制文件信息而代替一个读错误。系统里定义了和自己匹配的控制文件版本变量PG_CONTROL_VERSION，启动时会做系统和控制文件的匹配校验

 

pg_controldata命令

显示出控制文件中内容

 

与版本、平台迁移升级有关的信息

如果这些信息不同，即使在同一种Linux平台上，数据库也无法迁移或升级。在数据库启动过程中，读取控制文件后不能兼容会报“database files are incompatible with server”的错误

*pg_control version number：控制文件的版本

*Catalog version number：系统表版本号，PG9.4版本为201409291.PG版本由三个数字表示“X.Y.Z”，通常有重大功能变化X才会发生变化，Y变化通常指系统表发生了变化，Z变化系统表不会变化。若只是Z变化，通常只需要把二进制程序升级一个就可以，系统表没有变化，数据文件就是可以兼容

*Maximum data alignment：数据结构最大的对齐值

*Database block size：数据块的大小

*Blocks per segment of large relation：在一些文件系统上，单个文件大小受限制，PG会把一个表的数据分到多个数据文件中存储，此值制定了每个数据文件最多多少个数据块，默认为131072个块，每个块8k，数据文件最大为1G

*WAL block size：WAL日志块大小

*Bytes per WAL segment：WAL日志块大小

*Maximum length of identifiers：“name”类型的长度，实际上指一些数据库对象名称的最大长度，如表名、索引名的最大长度

*Maximum columns in an index：一个索引最多多少列，目前为32个

*Maximum size of a TOAST chunk：TOAST chunk的长度

*Size of a large-object chunk：大对象的chunk大小

*Date/time type storage：Date/time类型是用浮点数（double）类型表示还是由64bit的长整数表示，与不同类UNIX平台有关

*Float4 argument passing：Float4类型的参数是传值还是传引用

*Float8 argument passing：Float8类型的参数是传值还是传引用

*Data page checksum version：数据块checksum的版本，如果为0，数据块没有使用checksum。运行initdb时加了-k参数，PG才会在数据块上启用checksum功能

 

数据库的唯一标识串

Database system identifier，这个标识串是一个64bit的整数，其中包含了创建数据库的时间戳和initdb时初始化的进程号，因此通常不会重复

 

记录实例的状态

Database cluster state

*starting up：表示数据库正在启动状态，实际上目前没有使用此状态

*shut down：数据库实例（非Standby）正常关闭后控制文件中就是此状态

*shut down in recovery：Standby实例正常关闭后控制文件中就是此状态

*shutting down：正常停库时，先做checkpoint，开始做checkpoint时，会把状态设置为此状态，做完后把状态设置为shut down

*in crash recovery：数据库实例非异常停止后，重新启动后，会先进行实例的恢复，在实例恢复时的状态就是此状态

*in archive recovery：Standby实例正常启动后，就是此状态

*in production：数据库实例正常启动后就是此状态。Standby数据库正常启动后不是此状态

 

PG异常重启后的实例恢复、物理备份的信息

*Latest checkpoint location：数据库异常停止后再重新启动时，需要做实例恢复，实例恢复的过程是从WAL日志中，找到最后一次的checkpoint点，然后读取这个点之后的WAL日志，重新应用这些日志，此过程称为数据库实例前滚，最后一次的checkpoint点的信息记录在“Latest checkpont”项中

*Minimum recovery ending location：此值与Standby库应用WAL日志有关，需要注意的是主库与备库的控制文件中的checkpoint信息不同。在备库中，每replay一些WAL日志后，就会做一次checkpoint点，然后把这个checkpoint点的信息记录到控制文件中。当在备库replay一些日志，如果有一些脏数据刷新到磁盘中，会把产生脏数据的最新日志的位置记录到“Minimum recovery ending location”。为了能保证恢复到一个一致点。备库异常停机后，再启动，若备库提供只读服务或激活成主库，磁盘上的数据不一致，此时读备库会读到错误数据。因此replay日志要超过“Minimum recovery ending location”后，才能对外提供服务

 

热备相关

*Backup start location

*Backup end location

*End-of-backup record required

“Backup start location”与“Backup end location”记录了一个WAL日志的位置。在主库上做“SELECT pg_start_backup(‘tangxxxx’);”，只是在主库的数据目录下生成了一个backup_label文件，这时拷贝主库，拷贝出来的数据文件中就包括了backup_label文件，备库启动时，若发现有backup_label文件，会从这个文件中记录的点开始恢复，同时备库会把此位置记录到控制文件的“Backup start location”中，

“Backup end location”与“End-of-backup record required”记录了备库恢复过程中的一些中间状态