8,028
社区成员
发帖
与我相关
我的任务
分享PG wal 日志的物理存储分析
PG wal 日志的物理存储分析
原文链接： http://www.postgres.cn/v2/news/viewone/1/385?tdsourcetag=s_pcqq_aiomsg
摘要
事务日志是数据库的重要组成部分，存储了数据库系统中所有更改和操作的历史，以确保数据库不会因为故障(例如掉电或其他导致服务器崩溃的故障)而丢失数据。在PostgreSQL(以下简称PG)中，事务日志文件称为Write Ahead Log（以下简称WAL）。
本文对PG中事务日志文件的结构进行了简要的剖析，内容包括WAL基本术语、WAL文件组成、WAL segment file内部结构和内容剖析、XLOG Record内存组织以及 pg_waldump 工具简介。本篇是第一部分，内容包括WAL基本术语、WAL文件组成以及WAL segment file的内部结构。
一、WAL基本术语
为了更好的理解WAL和便于沟通，有必要首先对相关的WAL术语进行简要的介绍。
1、REDO log
Redo log通常称为重做日志，在写入数据文件前，每个变更都会先行写入到Redo log中。其用途和意义在于存储数据库的所有修改历史，用于数据库故障恢复（Recovery）、增量备份（Incremental Backup）、PITR(Point In Time Recovery)和复制（Replication）。
2、WAL segment file
为了便于管理，PG把事务日志文件划分为N个segment，每个segment称为WAL segment file，每个WAL segment file大小默认为16MB。
3、XLOG Record
这是一个逻辑概念，可以理解为PG中的每一个变更都对应一条XLOG Record，这些XLOG Record存储在WAL segment file中。PG读取这些XLOG Record进行故障恢复/PITR等操作。
4、WAL buffer
WA缓冲区，不管是WAL segment file的header还是XLOG Record都会先行写入到WAL缓冲区中，在"合适的时候"再通过WAL writer写入到WAL segment file中。
5、LSN
LSN即日志序列号Log Sequence Number。表示XLOG record记录写入到事务日志中位置。LSN的值为无符号64位整型（uint64）。在事务日志中，LSN单调递增且唯一。
6、checkpointer
checkpointer是PG中的一个后台进程，该进程周期性地执行checkpoint。当执行checkpoint时，该进程会把包含checkpoint信息的XLOG Record写入到当前的WAL segment file中，该XLOG Record记录包含了最新Redo pint的位置。
7、checkpoint
检查点checkpoint由checkpointer进程执行，主要的处理流程如下：
获取Redo point，构造包含此Redo point检查点（详细请参考Checkpoint结构体）信息的XLOG Record并写入到WAL segment file中；
刷新Dirty Page到磁盘上；
更新Redo point等信息到 pg_control 文件中。
8、REDO point
REDO point是PG启动恢复的起始点，是最后一次checkpoint启动时事务日志文件的末尾亦即写入Checkpoint XLOG Record时的位置（这里的位置可以理解为事务日志文件中偏移量）。
9、 pg_control
pg_control 是磁盘上的物理文件，保存检查点的基本信息，在数据库恢复中使用，可通过命令 pg_controldata 查看该文件中的内容。
二、WAL文件组成
如前所述，事务日志存储了数据库系统中所有更改和操作的历史，随着数据库的运行，事务日志大小不断的增长，那么事务日志有大小限制吗？在PG中，答案是肯定的：大小有限制。
PG使用无符号64bit整型（uint64）作为事务日志文件的寻址空间，理论上，PG的事务日志空间最大为2^64Bytes(即16EB)。这个大小有多大呢？假设某个数据库比较繁忙，每天可以产生16TB的日志文件，那么要达到事务日志文件大小的上限需要的时间是1024*1024/365天≈2800年。也就是说，虽然大小有限制，但从现阶段来看已然足够了。
显然，对于16EB的文件，OS是无法高效管理的，为此，PG把事务日志文件划分为N个大小为16M(默认值)的WAL segment file，其总体结构如下图所示：
图一 事务日志总体结构
1、WAL segment file
WAL segment file文件名称为24个字符，由3部分组成，每个部分是8个字符，每个字符是一个16进制值（即0~F）。每一部分的解析如下（在WAL segment file文件大小为16MB的情况下）：
第1部分是TimeLineID，取值范围是0x00000000 -> 0xFFFFFFFF
第2部分是逻辑文件ID，取值范围是0x00000000 -> 0xFFFFFFFF
第3部分是物理文件ID，取值范围是0x00000000 -> 0x000000FF
逻辑文件ID、物理文件ID和文件大小这三部分的组合，实现了64bit的寻找空间：
逻辑文件ID是32bit的uint32（unsigned int 32bit）
物理文件ID是8bit的unit8
16M的文件大小是24bit的unit24
三者共同组成unit64（32+8+24），达到最大64bit的文件寻址空间。
2、再谈LSN
事务日志文件的LSN表示XLOG Record记录写入到事务日志文件中的位置。LSN可以理解为XLOG Record在事务日志文件中的偏移(Offset)。
LSN由3部分组成，分别是逻辑文件ID，物理文件ID和文件内偏移。如LSN：1/4288E228，其中1为逻辑文件ID，42为物理文件ID，88E228为WAL segment file文件内偏移（注：3Bytes的寻找空间为16MB）。
按此规则,给定一个LSN，很容易根据LSN号推算得到其对应的日志文件(假定时间线TimeLineID为1)。
如：LSN 1/4288E228对应的WAL segment file文件为00000001 00000001 00000042，该文件名称的前8位为时间线ID（00000001），中间8位（00000001）为逻辑文件ID，最后8位（00000042）为物理文件ID。
另外，PG也提供了相应的函数根据LSN获取日志文件名：
testdb=# SELECT pg_walfile_name('1/4288E228');
pg_walfile_name
--------------------------
000000010000000100000042
(1 row)
三、WAL segment file内部结构
WAL segment file默认大小为16MB,其内部结构如下图所示：
图二 WAL segment file内部结构
1、WAL segment file
WAL segment file内部划分为N个page(Block)，每个page大小为8192 Bytes即8K，每个WAL segment file第1个page的header在PG源码中相应的数据结构是XLogLongPageHeaderData，后续其他page的header对应的数据结构是XLogPageHeaderData。在一个page中，page header之后是N个XLOG Record。
2、XLOG Record
XLOG Record由两部分组成，第一部分是XLOG Record的头部信息，大小固定（24 Bytes），对应的结构体是XLogRecord；第二部分是XLOG Record data。
XLOG Record的整体布局如下:
头部数据(固定大小的XLogRecord结构体)
XLogRecordBlockHeader 结构体
XLogRecordBlockHeader 结构体
...
XLogRecordDataHeader[Short|Long] 结构体
block data
block data
...
main data
XLOG Record按存储的数据内容来划分，大体可以分为三类：
Record for backup block：存储full-write-page的block，这种类型Record是为了解决page部分写的问题。在checkpoint完成后第一次修改数据page，在记录此变更写入事务日志文件时整页写入（需设置相应的初始化参数，默认为打开）；
Record for tuple data block：存储page中的tuple变更，使用这种类型的Record记录；
Record for Checkpoint：在checkpoint发生时，在事务日志文件中记录checkpoint信息(其中包括Redo point)。
其中XLOG Record data是存储实际数据的地方，由以下几部分组成：
0..N个XLogRecordBlockHeader，每一个XLogRecordBlockHeader对应一个block data；
XLogRecordDataHeader[Short|Long]，如数据大小<256 Bytes，则使用Short格式，否则使用Long格式；
block data：full-write-page data和tuple data。对于full-write-page data，如启用了压缩，则数据压缩存储，压缩后该page相关的元数据存储在XLogRecordBlockCompressHeader中；
main data： /checkpoint等日志数据.
以INSERT数据为例，在插入数据时的XLOG Record data内部结构如下图所示:
图三 XLOG Record data for DML Statement
3、数据结构
1、XLogPageHeaderData结构体定义
/*
* Each page of XLOG file has a header like this:
* 每一个事务日志文件的page都有头部信息,结构如下:
*/
//可作为WAL版本信息
#define XLOG_PAGE_MAGIC 0xD098 /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
//WAL版本信息,PG V11.1 --> 0xD98
uint16 xlp_magic; /* magic value for correctness checks */
//标记位(详见下面说明)
uint16 xlp_info; /* flag bits, see below */
//page中第一个XLOG Record的TimeLineID,类型为uint32
TimeLineID xlp_tli; /* TimeLineID of first record on page */
//page的XLOG地址(在事务日志中的偏移),类型为uint64
XLogRecPtr xlp_pageaddr; /* XLOG address of this page */
/*
* When there is not enough space on current page for whole record, we
* continue on the next page. xlp_rem_len is the number of bytes
* remaining from a previous page.
* 如果当前页的空间不足以存储整个XLOG Record,在下一个页面中存储余下的数据
* xlp_rem_len表示上一页XLOG Record剩余部分的大小
*
* Note that xl_rem_len includes backup-block data; that is, it tracks
* xl_tot_len not xl_len in the initial header. Also note that the
* continuation data isn't necessarily aligned.
* 注意xl_rem_len包含backup-block data(full-page-write);
* 也就是说在初始的头部信息中跟踪的是xl_tot_len而不是xl_len.
* 另外要注意的是剩余的数据不需要对齐.
*/
//上一页空间不够存储XLOG Record,该Record在本页继续存储占用的空间大小
uint32 xlp_rem_len; /* total len of remaining data for record */
} XLogPageHeaderData;
#define SizeOfXLogShortPHD MAXALIGN(sizeof(XLogPageHeaderData))
typedef XLogPageHeaderData *XLogPageHeader;
2、XLogLongPageHeaderData结构体定义
/*
* When the XLP_LONG_HEADER flag is set, we store additional fields in the
* page header. (This is ordinarily done just in the first page of an
* XLOG file.) The additional fields serve to identify the file accurately.
* 如设置了XLP_LONG_HEADER标记,在page header中存储额外的字段.
* (通常在每个事务日志文件也就是segment file的的第一个page中存在).
* 附加字段用于准确识别文件。
*/
typedef struct XLogLongPageHeaderData
{
//标准的头部域字段
XLogPageHeaderData std; /* standard header fields */
//pg_control中的系统标识码
uint64 xlp_sysid; /* system identifier from pg_control */
//交叉检查
uint32 xlp_seg_size; /* just as a cross-check */
//交叉检查
uint32 xlp_xlog_blcksz; /* just as a cross-check */
} XLogLongPageHeaderData;
#define SizeOfXLogLongPHD MAXALIGN(sizeof(XLogLongPageHeaderData))
//指针
typedef XLogLongPageHeaderData *XLogLongPageHeader;
/* When record crosses page boundary, set this flag in new page's header */
//如果XLOG Record跨越page边界,在新page header中设置该标志位
#define XLP_FIRST_IS_CONTRECORD 0x0001
//该标志位标明是"long"页头
/* This flag indicates a "long" page header */
#define XLP_LONG_HEADER 0x0002
/* This flag indicates backup blocks starting in this page are optional */
//该标志位标明从该页起始的backup blocks是可选的(不一定存在)
#define XLP_BKP_REMOVABLE 0x0004
//xlp_info中所有定义的标志位(用于page header的有效性检查)
/* All defined flag bits in xlp_info (used for validity checking of header) */
#define XLP_ALL_FLAGS 0x0007
#define XLogPageHeaderSize(hdr) \
(((hdr)->xlp_info & XLP_LONG_HEADER) ? SizeOfXLogLongPHD : SizeOfXLogShortPHD)
3、XLogRecord结构体定义
/*
* The overall layout of an XLOG record is:
* Fixed-size header (XLogRecord struct)
* XLogRecordBlockHeader struct
* XLogRecordBlockHeader struct
* ...
* XLogRecordDataHeader[Short|Long] struct
* block data
* block data
* ...
* main data
* XLOG record的整体布局如下:
* 固定大小的头部(XLogRecord 结构体)
* XLogRecordBlockHeader 结构体
* XLogRecordBlockHeader 结构体
* ...
* XLogRecordDataHeader[Short|Long] 结构体
* block data
* block data
* ...
* main data
*
* There can be zero or more XLogRecordBlockHeaders, and 0 or more bytes of
* rmgr-specific data not associated with a block. XLogRecord structs
* always start on MAXALIGN boundaries in the WAL files, but the rest of
* the fields are not aligned.
* 其中,XLogRecordBlockHeaders可能有0或者多个,与block无关的0或多个字节的rmgr-specific数据
* XLogRecord通常在WAL文件的MAXALIGN边界起写入,但后续的字段并没有对齐
*
* The XLogRecordBlockHeader, XLogRecordDataHeaderShort and
* XLogRecordDataHeaderLong structs all begin with a single 'id' byte. It's
* used to distinguish between block references, and the main data structs.
* XLogRecordBlockHeader/XLogRecordDataHeaderShort/XLogRecordDataHeaderLong开头是占用1个字节的"id".
* 用于区分block依赖和main data结构体.
*/
typedef struct XLogRecord
{
//record的大小
uint32 xl_tot_len; /* total len of entire record */
//xact id
TransactionId xl_xid; /* xact id */
//指向log中的前一条记录
XLogRecPtr xl_prev; /* ptr to previous record in log */
//标识位,详见下面的说明
uint8 xl_info; /* flag bits, see below */
//该记录的资源管理器
RmgrId xl_rmid; /* resource manager for this record */
/* 2 bytes of padding here, initialize to zero */
//2个字节的crc校验位,初始化为0
pg_crc32c xl_crc; /* CRC for this record */
/* XLogRecordBlockHeaders and XLogRecordDataHeader follow, no padding */
//接下来是XLogRecordBlockHeaders和XLogRecordDataHeader
} XLogRecord;
//宏定义:XLogRecord大小
#define SizeOfXLogRecord (offsetof(XLogRecord, xl_crc) + sizeof(pg_crc32c))
/*
* The high 4 bits in xl_info may be used freely by rmgr. The
* XLR_SPECIAL_REL_UPDATE and XLR_CHECK_CONSISTENCY bits can be passed by
* XLogInsert caller. The rest are set internally by XLogInsert
原文链接： http://www.postgres.cn/v2/news/viewone/1/385?tdsourcetag=s_pcqq_aiomsg
摘要
事务日志是数据库的重要组成部分，存储了数据库系统中所有更改和操作的历史，以确保数据库不会因为故障(例如掉电或其他导致服务器崩溃的故障)而丢失数据。在PostgreSQL(以下简称PG)中，事务日志文件称为Write Ahead Log（以下简称WAL）。
本文对PG中事务日志文件的结构进行了简要的剖析，内容包括WAL基本术语、WAL文件组成、WAL segment file内部结构和内容剖析、XLOG Record内存组织以及 pg_waldump 工具简介。本篇是第一部分，内容包括WAL基本术语、WAL文件组成以及WAL segment file的内部结构。
一、WAL基本术语
为了更好的理解WAL和便于沟通，有必要首先对相关的WAL术语进行简要的介绍。
1、REDO log
Redo log通常称为重做日志，在写入数据文件前，每个变更都会先行写入到Redo log中。其用途和意义在于存储数据库的所有修改历史，用于数据库故障恢复（Recovery）、增量备份（Incremental Backup）、PITR(Point In Time Recovery)和复制（Replication）。
2、WAL segment file
为了便于管理，PG把事务日志文件划分为N个segment，每个segment称为WAL segment file，每个WAL segment file大小默认为16MB。
3、XLOG Record
这是一个逻辑概念，可以理解为PG中的每一个变更都对应一条XLOG Record，这些XLOG Record存储在WAL segment file中。PG读取这些XLOG Record进行故障恢复/PITR等操作。
4、WAL buffer
WA缓冲区，不管是WAL segment file的header还是XLOG Record都会先行写入到WAL缓冲区中，在"合适的时候"再通过WAL writer写入到WAL segment file中。
5、LSN
LSN即日志序列号Log Sequence Number。表示XLOG record记录写入到事务日志中位置。LSN的值为无符号64位整型（uint64）。在事务日志中，LSN单调递增且唯一。
6、checkpointer
checkpointer是PG中的一个后台进程，该进程周期性地执行checkpoint。当执行checkpoint时，该进程会把包含checkpoint信息的XLOG Record写入到当前的WAL segment file中，该XLOG Record记录包含了最新Redo pint的位置。
7、checkpoint
检查点checkpoint由checkpointer进程执行，主要的处理流程如下：
获取Redo point，构造包含此Redo point检查点（详细请参考Checkpoint结构体）信息的XLOG Record并写入到WAL segment file中；
刷新Dirty Page到磁盘上；
更新Redo point等信息到 pg_control 文件中。
8、REDO point
REDO point是PG启动恢复的起始点，是最后一次checkpoint启动时事务日志文件的末尾亦即写入Checkpoint XLOG Record时的位置（这里的位置可以理解为事务日志文件中偏移量）。
9、 pg_control
pg_control 是磁盘上的物理文件，保存检查点的基本信息，在数据库恢复中使用，可通过命令 pg_controldata 查看该文件中的内容。
二、WAL文件组成
如前所述，事务日志存储了数据库系统中所有更改和操作的历史，随着数据库的运行，事务日志大小不断的增长，那么事务日志有大小限制吗？在PG中，答案是肯定的：大小有限制。
PG使用无符号64bit整型（uint64）作为事务日志文件的寻址空间，理论上，PG的事务日志空间最大为2^64Bytes(即16EB)。这个大小有多大呢？假设某个数据库比较繁忙，每天可以产生16TB的日志文件，那么要达到事务日志文件大小的上限需要的时间是1024*1024/365天≈2800年。也就是说，虽然大小有限制，但从现阶段来看已然足够了。
显然，对于16EB的文件，OS是无法高效管理的，为此，PG把事务日志文件划分为N个大小为16M(默认值)的WAL segment file，其总体结构如下图所示：
图一 事务日志总体结构
1、WAL segment file
WAL segment file文件名称为24个字符，由3部分组成，每个部分是8个字符，每个字符是一个16进制值（即0~F）。每一部分的解析如下（在WAL segment file文件大小为16MB的情况下）：
第1部分是TimeLineID，取值范围是0x00000000 -> 0xFFFFFFFF
第2部分是逻辑文件ID，取值范围是0x00000000 -> 0xFFFFFFFF
第3部分是物理文件ID，取值范围是0x00000000 -> 0x000000FF
逻辑文件ID、物理文件ID和文件大小这三部分的组合，实现了64bit的寻找空间：
逻辑文件ID是32bit的uint32（unsigned int 32bit）
物理文件ID是8bit的unit8
16M的文件大小是24bit的unit24
三者共同组成unit64（32+8+24），达到最大64bit的文件寻址空间。
2、再谈LSN
事务日志文件的LSN表示XLOG Record记录写入到事务日志文件中的位置。LSN可以理解为XLOG Record在事务日志文件中的偏移(Offset)。
LSN由3部分组成，分别是逻辑文件ID，物理文件ID和文件内偏移。如LSN：1/4288E228，其中1为逻辑文件ID，42为物理文件ID，88E228为WAL segment file文件内偏移（注：3Bytes的寻找空间为16MB）。
按此规则,给定一个LSN，很容易根据LSN号推算得到其对应的日志文件(假定时间线TimeLineID为1)。
如：LSN 1/4288E228对应的WAL segment file文件为00000001 00000001 00000042，该文件名称的前8位为时间线ID（00000001），中间8位（00000001）为逻辑文件ID，最后8位（00000042）为物理文件ID。
另外，PG也提供了相应的函数根据LSN获取日志文件名：
testdb=# SELECT pg_walfile_name('1/4288E228');
pg_walfile_name
--------------------------
000000010000000100000042
(1 row)
三、WAL segment file内部结构
WAL segment file默认大小为16MB,其内部结构如下图所示：
图二 WAL segment file内部结构
1、WAL segment file
WAL segment file内部划分为N个page(Block)，每个page大小为8192 Bytes即8K，每个WAL segment file第1个page的header在PG源码中相应的数据结构是XLogLongPageHeaderData，后续其他page的header对应的数据结构是XLogPageHeaderData。在一个page中，page header之后是N个XLOG Record。
2、XLOG Record
XLOG Record由两部分组成，第一部分是XLOG Record的头部信息，大小固定（24 Bytes），对应的结构体是XLogRecord；第二部分是XLOG Record data。
XLOG Record的整体布局如下:
头部数据(固定大小的XLogRecord结构体)
XLogRecordBlockHeader 结构体
XLogRecordBlockHeader 结构体
...
XLogRecordDataHeader[Short|Long] 结构体
block data
block data
...
main data
XLOG Record按存储的数据内容来划分，大体可以分为三类：
Record for backup block：存储full-write-page的block，这种类型Record是为了解决page部分写的问题。在checkpoint完成后第一次修改数据page，在记录此变更写入事务日志文件时整页写入（需设置相应的初始化参数，默认为打开）；
Record for tuple data block：存储page中的tuple变更，使用这种类型的Record记录；
Record for Checkpoint：在checkpoint发生时，在事务日志文件中记录checkpoint信息(其中包括Redo point)。
其中XLOG Record data是存储实际数据的地方，由以下几部分组成：
0..N个XLogRecordBlockHeader，每一个XLogRecordBlockHeader对应一个block data；
XLogRecordDataHeader[Short|Long]，如数据大小<256 Bytes，则使用Short格式，否则使用Long格式；
block data：full-write-page data和tuple data。对于full-write-page data，如启用了压缩，则数据压缩存储，压缩后该page相关的元数据存储在XLogRecordBlockCompressHeader中；
main data： /checkpoint等日志数据.
以INSERT数据为例，在插入数据时的XLOG Record data内部结构如下图所示:
图三 XLOG Record data for DML Statement
3、数据结构
1、XLogPageHeaderData结构体定义
/*
* Each page of XLOG file has a header like this:
* 每一个事务日志文件的page都有头部信息,结构如下:
*/
//可作为WAL版本信息
#define XLOG_PAGE_MAGIC 0xD098 /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
//WAL版本信息,PG V11.1 --> 0xD98
uint16 xlp_magic; /* magic value for correctness checks */
//标记位(详见下面说明)
uint16 xlp_info; /* flag bits, see below */
//page中第一个XLOG Record的TimeLineID,类型为uint32
TimeLineID xlp_tli; /* TimeLineID of first record on page */
//page的XLOG地址(在事务日志中的偏移),类型为uint64
XLogRecPtr xlp_pageaddr; /* XLOG address of this page */
/*
* When there is not enough space on current page for whole record, we
* continue on the next page. xlp_rem_len is the number of bytes
* remaining from a previous page.
* 如果当前页的空间不足以存储整个XLOG Record,在下一个页面中存储余下的数据
* xlp_rem_len表示上一页XLOG Record剩余部分的大小
*
* Note that xl_rem_len includes backup-block data; that is, it tracks
* xl_tot_len not xl_len in the initial header. Also note that the
* continuation data isn't necessarily aligned.
* 注意xl_rem_len包含backup-block data(full-page-write);
* 也就是说在初始的头部信息中跟踪的是xl_tot_len而不是xl_len.
* 另外要注意的是剩余的数据不需要对齐.
*/
//上一页空间不够存储XLOG Record,该Record在本页继续存储占用的空间大小
uint32 xlp_rem_len; /* total len of remaining data for record */
} XLogPageHeaderData;
#define SizeOfXLogShortPHD MAXALIGN(sizeof(XLogPageHeaderData))
typedef XLogPageHeaderData *XLogPageHeader;
2、XLogLongPageHeaderData结构体定义
/*
* When the XLP_LONG_HEADER flag is set, we store additional fields in the
* page header. (This is ordinarily done just in the first page of an
* XLOG file.) The additional fields serve to identify the file accurately.
* 如设置了XLP_LONG_HEADER标记,在page header中存储额外的字段.
* (通常在每个事务日志文件也就是segment file的的第一个page中存在).
* 附加字段用于准确识别文件。
*/
typedef struct XLogLongPageHeaderData
{
//标准的头部域字段
XLogPageHeaderData std; /* standard header fields */
//pg_control中的系统标识码
uint64 xlp_sysid; /* system identifier from pg_control */
//交叉检查
uint32 xlp_seg_size; /* just as a cross-check */
//交叉检查
uint32 xlp_xlog_blcksz; /* just as a cross-check */
} XLogLongPageHeaderData;
#define SizeOfXLogLongPHD MAXALIGN(sizeof(XLogLongPageHeaderData))
//指针
typedef XLogLongPageHeaderData *XLogLongPageHeader;
/* When record crosses page boundary, set this flag in new page's header */
//如果XLOG Record跨越page边界,在新page header中设置该标志位
#define XLP_FIRST_IS_CONTRECORD 0x0001
//该标志位标明是"long"页头
/* This flag indicates a "long" page header */
#define XLP_LONG_HEADER 0x0002
/* This flag indicates backup blocks starting in this page are optional */
//该标志位标明从该页起始的backup blocks是可选的(不一定存在)
#define XLP_BKP_REMOVABLE 0x0004
//xlp_info中所有定义的标志位(用于page header的有效性检查)
/* All defined flag bits in xlp_info (used for validity checking of header) */
#define XLP_ALL_FLAGS 0x0007
#define XLogPageHeaderSize(hdr) \
(((hdr)->xlp_info & XLP_LONG_HEADER) ? SizeOfXLogLongPHD : SizeOfXLogShortPHD)
3、XLogRecord结构体定义
/*
* The overall layout of an XLOG record is:
* Fixed-size header (XLogRecord struct)
* XLogRecordBlockHeader struct
* XLogRecordBlockHeader struct
* ...
* XLogRecordDataHeader[Short|Long] struct
* block data
* block data
* ...
* main data
* XLOG record的整体布局如下:
* 固定大小的头部(XLogRecord 结构体)
* XLogRecordBlockHeader 结构体
* XLogRecordBlockHeader 结构体
* ...
* XLogRecordDataHeader[Short|Long] 结构体
* block data
* block data
* ...
* main data
*
* There can be zero or more XLogRecordBlockHeaders, and 0 or more bytes of
* rmgr-specific data not associated with a block. XLogRecord structs
* always start on MAXALIGN boundaries in the WAL files, but the rest of
* the fields are not aligned.
* 其中,XLogRecordBlockHeaders可能有0或者多个,与block无关的0或多个字节的rmgr-specific数据
* XLogRecord通常在WAL文件的MAXALIGN边界起写入,但后续的字段并没有对齐
*
* The XLogRecordBlockHeader, XLogRecordDataHeaderShort and
* XLogRecordDataHeaderLong structs all begin with a single 'id' byte. It's
* used to distinguish between block references, and the main data structs.
* XLogRecordBlockHeader/XLogRecordDataHeaderShort/XLogRecordDataHeaderLong开头是占用1个字节的"id".
* 用于区分block依赖和main data结构体.
*/
typedef struct XLogRecord
{
//record的大小
uint32 xl_tot_len; /* total len of entire record */
//xact id
TransactionId xl_xid; /* xact id */
//指向log中的前一条记录
XLogRecPtr xl_prev; /* ptr to previous record in log */
//标识位,详见下面的说明
uint8 xl_info; /* flag bits, see below */
//该记录的资源管理器
RmgrId xl_rmid; /* resource manager for this record */
/* 2 bytes of padding here, initialize to zero */
//2个字节的crc校验位,初始化为0
pg_crc32c xl_crc; /* CRC for this record */
/* XLogRecordBlockHeaders and XLogRecordDataHeader follow, no padding */
//接下来是XLogRecordBlockHeaders和XLogRecordDataHeader
} XLogRecord;
//宏定义:XLogRecord大小
#define SizeOfXLogRecord (offsetof(XLogRecord, xl_crc) + sizeof(pg_crc32c))
/*
* The high 4 bits in xl_info may be used freely by rmgr. The
* XLR_SPECIAL_REL_UPDATE and XLR_CHECK_CONSISTENCY bits can be passed by
* XLogInsert caller. The rest are set internally by XLogInsert
...全文
请发表友善的回复…
发表回复
