设为首页 收藏本站
查看: 1004|回复: 0

[经验分享] PostgreSQL的存储系统一:控制文件存储结构

[复制链接]

尚未签到

发表于 2016-11-21 05:00:04 | 显示全部楼层 |阅读模式
Pg 控制文件pg_control里存储的数据是一个ControlFileData结构。控制文件尽量保持小于512个字节以使其适合一个典型的磁盘驱动的物理簇的大小。这会减少由于电源故障而写控制文件直接失败的可能性。但控制文件的物理大小是8K,这个远大于512个字节。这样做是为了控制文件格式变化时保持物理大小不变,如果正在读一个不兼容的文件,以使ReadControlFile能传递一个合适的错误版本控制文件信息而代替一个读错误。系统里定义了和自己匹配的控制文件版本变量PG_CONTROL_VERSION,启动时会做系统和控制文件的匹配校验。
1
控制文件里存储了唯一系统标识符、系统状态数据、数据库启动前系统必须恢复到的最小点、检查服务器硬件架构计算能力的字节排序和浮点数格式、数据库的配置兼容backend进程执行的参数、指明类型timestamp、interval、time内部格式的标志、指明不同类型传值(pass-by-value)状态的标志以及所有这些信息的经验和。具体见下面ControlFileData结构。
 

typedef struct ControlFileData

{

    /*唯一系统标识符——保证控制文件和产生XLOG文件的数据库一致*/

    uint64     system_identifier;

    /*

版本标识符信息。保持这些制度在同一个偏移量,特别是pg_control_version;如果它们改变了他们就不再有用。(由于历史原因他们必须在文件里是8字节,而不是在最前面。)

    pg_control_version标识pg_control自身的格式。

    catalog_version_no标识系统catalog的格式。

    在私有文件里有额外的版本标识符;例如,WAL日志文件每页包含的magic数可以作为WAL日志的版本。

     */

    uint32     pg_control_version;      /*PG_CONTROL_VERSION */

    uint32     catalog_version_no;      /* seecatversion.h */

 

    /*系统状态数据*/

    DBState       state;        /* see enumabove */

    pg_time_t  time;         /* time stamp of last pg_control update */

    XLogRecPtr checkPoint;       /* last check point record ptr*/

    XLogRecPtr prevCheckPoint; /* previous check point record ptr*/

 

    CheckPoint checkPointCopy; /* copy of last check point record */

 

    /*

这两个值确定数据库启动前我们必须恢复到的最小点:
    我们在归档恢复期间刷出数据的时候minRecoveryPoint被更新到最后重放的LSN。这保证了归档恢复,退出并且在更早的停止位置启动 并恢复到这个位置。如果我们已经从内存里把新的WAL记录X刷出到磁盘,没有到达X我们决不能启动。没有做归档恢复时minRecoveryPoint0
    backupStartPoint:如果我们正在从在线备份恢复而且还没有到达备份的结尾,backupStartPoint是备份开始检查点的redo指针。到达备份结尾后置backupStartPoint0并且到达它之前我们不能启动数据库。负责一个布尔值就足够了,但是当我们看到一个end-of-backup记录时我们用这个redo指针做检查,以保证这个end-of-backup记录是我们正在基于其恢复的那个基础备份。
     */

    XLogRecPtr minRecoveryPoint;

    XLogRecPtr backupStartPoint;

 

    /* 确定WAL能被用于归档或双机热备的参数设置 */

    int        wal_level;

    int        MaxConnections;

    int        max_prepared_xacts;

    int        max_locks_per_xact;

 

    /*

这些数据用来检查数据库和backend进程在其上执行的硬件架构计算能力。我们不需要显式检查字节顺序(endianness),因为对于一个不同字节顺序的机器控制文件版本会看到问题,但我们需要担心字节对齐和浮点格式。(注意:磁盘存储布局通常依赖于SHORTALIGNINTALIGN,但实际上在所有感兴趣的架构上它们是相同的。)

    对于浮点兼容仅测试一个double值不是个刀枪不入的测试,但会满足大多数场合。

     */

    uint32     maxAlign;     /* alignment requirement for tuples */

    double     floatFormat/* constant1234567.0 */

#define FLOATFORMAT_VALUE   1234567.0

 

    /* 这些数据用来确保数据库的配置兼容backend进程执行 */

    uint32     blcksz;           /* data block size for this DB */

    uint32     relseg_size/* blocks per segment of large relation */

 

    uint32     xlog_blcksz/* block size within WAL files */

    uint32     xlog_seg_size;    /* size of each WAL segment */

 

    uint32     nameDataLen/* catalog name field width */

    uint32     indexMaxKeys; /* max number of columns in an index */

 

    uint32     toast_max_chunk_size;    /* chunksize in TOAST tables */

 

    /* 指明内部timestampintervaltime内部格式的标志 */

    bool       enableIntTimes; /* int64 storage enabled? */

 

    /* 指明不同类型pass-by-value状态的标志 */

    bool       float4ByVal/* float4 pass-by-value? */

    bool       float8ByVal/* float8, int8, etc pass-by-value? */

 

    /* CRC of all above ... MUST BE LAST! */

    pg_crc32   crc;

} ControlFileData;

 

    其中的成员statecheckPointCopycheckPointprevCheckPointminRecoveryPointbackupStartPoint需要说明

 

2

成员stateDBState枚举类型变量。作系统状态指示器。存储于控制文件,如果改变了该枚举类型,必须修改控制文件版本和系统内变量PG_CONTROL_VERSION。定义见下面。

 

typedef enum DBState

{

    DB_STARTUP = 0,

    DB_SHUTDOWNED,

    DB_SHUTDOWNED_IN_RECOVERY,

    DB_SHUTDOWNING,

    DB_IN_CRASH_RECOVERY,

    DB_IN_ARCHIVE_RECOVERY,

    DB_IN_PRODUCTION

} DBState;

 

3

成员checkPointCopyCheckPoint类型变量,就是常说的检查点,是最后的那个检查点的拷贝,以备灾难恢复是使用,改变该结构定义要求改变控制文件版本和系统内变量PG_CONTROL_VERSION。定义见下面。

 

typedef struct CheckPoint

{

    XLogRecPtr redo;         /*开始创建一个检查点时下一个XLOG记录的位置*/

    TimeLineID ThisTimeLineID; /*当前时间线*/

    uint32     nextXidEpoch; /*下一个事务ID的高排序位 */

    TransactionId nextXid;      /* 下一个空闲事务ID */

    Oid        nextOid;      /* 下一个空闲OID */

    MultiXactId nextMulti;      /* 下一个空闲多事务ID */

    MultiXactOffset nextMultiOffset;   /* next free MultiXact offset */

    TransactionId oldestXid; /* cluster-wide minimum datfrozenxid*/

    Oid        oldestXidDB/* database with minimum datfrozenxid*/

    pg_time_t  time;         /* 检查点时间戳 */

 

    /*

仍在运行的最早的事务IDXID)。只有在从一个在线检查点初始化热备模式时才需要,以使在GUC参数wal_levelhot_standby时我们不用为在线检查点计算运行最早的XID。否则设置为常量InvalidTransactionId

     */

    TransactionId oldestActiveXid;

} CheckPoint;
 

4

    成员checkPointprevCheckPointminRecoveryPointbackupStartPointXLogRecPtr结构类型的变量。先看XLogRecPtr结构类型,用于记录XLOG记录在XLOG日志文件中的位置,下面是其结构定义:

typedef struct XLogRecPtr

{

    uint32     xlogid;           /* 逻辑XLOG日志文件ID,从0开始 */

    uint32     xrecoff;      /* XLOG日志文件里的字节偏移量 */

} XLogRecPtr;

 

注意:这儿容易引起理解错乱,这个xlogid(对应实际XLOG文件名字的中间八位)表示逻辑XLOG日志文件ID,因为组成XLOG逻辑文件的实际物理文件远小于4Gb。组成对应这个xlogid的逻辑日志文件的每一个实际物理文件是一个XLogSegSize字节大小的“段”("segment",段号是实际XLOG文件名字的后八位)。前面加上用八位表示的一个时间线ID、逻辑日志文件号和段号一起标识一个物理的XLOG日志文件(“段”)。段号和物理文件里的偏移量由xrecoff/XLogSegSizexrecoff%XLogSegSize计算。

 

checkPoint表示最后的检查点记录指针、prevCheckPoint表示最后检查点的前一个检查点记录指针、minRecoveryPoint表示数据库从归档恢复的时候的最小恢复点、backupStartPoint表示数据库从备份恢复的时候的备份起始点。

 

 ------------
转载请著明出处,来自博客:
blog.csdn.net/beiigang
beigang.iyunv.com

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-303030-1-1.html 上篇帖子: PostgreSQL启动过程中的那些事十六:StartDataBase梗概 下篇帖子: PostgreSQL启动过程中的那些事十七:ServerLoop
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表