PostgreSQL 事务日志WAL结构浅析

作者: EthanHe | 来源:发表于2018-12-21 15:32 被阅读16次

摘要

事务日志是数据库的重要组成部分，存储了数据库系统中所有更改和操作的历史，以确保数据库不会因为故障(例如掉电或其他导致服务器崩溃的故障)而丢失数据。在PostgreSQL(以下简称PG)中，事务日志文件称为Write Ahead Log（以下简称WAL）。

本文对PG中事务日志文件的结构进行了简要的剖析，内容包括WAL基本术语、WAL文件组成、WAL segment file内部结构和内容剖析以及pg_waldump工具简介。

一、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进程执行，主要的处理流程如下：

(1) 获取Redo point，构造包含此Redo point检查点（详细请参考Checkpoint结构体）信息的XLOG Record并写入到WAL segment file中；

(2) 刷新Dirty Page到磁盘上；

(3) 更新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 结构体

...

XLogRecordDataHeader[Short|Long] 结构体

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

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.

 * xl_info的高4位由rmgr自由使用.

 * XLR_SPECIAL_REL_UPDATE和XLR_CHECK_CONSISTENCY由XLogInsert函数的调用者传入.

* 其余由XLogInsert内部使用.

 */

#define XLR_INFO_MASK 0x0F

#define XLR_RMGR_INFO_MASK 0xF0

/*

 * If a WAL record modifies any relation files, in ways not covered by the

 * usual block references, this flag is set. This is not used for anything

 * by PostgreSQL itself, but it allows external tools that read WAL and keep

 * track of modified blocks to recognize such special record types.

* 如果WAL记录使用特殊的方式(不涉及通常块引用)更新了关系的存储文件,设置此标记.

 * PostgreSQL本身并不使用这种方法，但它允许外部工具读取WAL并跟踪修改后的块，

* 以识别这种特殊的记录类型。

 */

#define XLR_SPECIAL_REL_UPDATE 0x01

/*

 * Enforces consistency checks of replayed WAL at recovery. If enabled,

 * each record will log a full-page write for each block modified by the

 * record and will reuse it afterwards for consistency checks. The caller

 * of XLogInsert can use this value if necessary, but if

 * wal_consistency_checking is enabled for a rmgr this is set unconditionally.

* 在恢复时强制执行一致性检查.

* 如启用此功能,每个记录将为记录修改的每个块记录一个完整的页面写操作，并在以后重用它进行一致性检查。

* 在需要时,XLogInsert的调用者可使用此标记,但如果rmgr启用了wal_consistency_checking,

* 则会无条件执行一致性检查.

 */

#define XLR_CHECK_CONSISTENCY 0x02

4) XLogRecordBlockHeader结构体定义


/*

 * Header info for block data appended to an XLOG record.

* 追加到XLOG record中block data的头部信息

 *

 * 'data_length' is the length of the rmgr-specific payload data associated

 * with this block. It does not include the possible full page image, nor

 * XLogRecordBlockHeader struct itself.

 * 'data_length'是与此块关联的rmgr特定payload data的长度。

* 它不包括可能的full page image，也不包括XLogRecordBlockHeader结构体本身。

 *

 * Note that we don't attempt to align the XLogRecordBlockHeader struct!

 * So, the struct must be copied to aligned local storage before use.

* 注意:我们不打算尝试对齐XLogRecordBlockHeader结构体!

* 因此,在使用前,XLogRecordBlockHeader必须拷贝到对齐的本地存储中.

 */

typedef struct XLogRecordBlockHeader

{

 //块引用ID

 uint8 id; /* block reference ID */

 //在关系中使用的fork和flags

 uint8 fork_flags; /* fork within the relation, and flags */

 //payload字节大小

 uint16 data_length; /* number of payload bytes (not including page

 * image) */

 /* If BKPBLOCK_HAS_IMAGE, an XLogRecordBlockImageHeader struct follows */

/* If BKPBLOCK_SAME_REL is not set, a RelFileNode follows */

/* BlockNumber follows */

 //如BKPBLOCK_HAS_IMAGE,后续为XLogRecordBlockImageHeader结构体   

 //如BKPBLOCK_SAME_REL没有设置,则为RelFileNode

 //后续为BlockNumber

} XLogRecordBlockHeader;

#define SizeOfXLogRecordBlockHeader (offsetof(XLogRecordBlockHeader, data_length) + sizeof(uint16))

5) XLogRecordDataHeader[Short|Long]结构体定义


 /*

 * XLogRecordDataHeaderShort/Long are used for the "main data" portion of

 * the record. If the length of the data is less than 256 bytes, the short

 * form is used, with a single byte to hold the length. Otherwise the long

 * form is used.

 * XLogRecordDataHeaderShort/Long用于记录的“main data”部分。

* 如果数据的长度小于256字节，则使用短格式，用一个字节保存长度。

* 否则使用长形式。

 *

 * (These structs are currently not used in the code, they are here just for

 * documentation purposes).

 * (这些结构体不会再代码中使用,在这里是为了文档记录的目的)

 */

typedef struct XLogRecordDataHeaderShort

{

 uint8 id; /* XLR_BLOCK_ID_DATA_SHORT */

 uint8 data_length; /* number of payload bytes */

} XLogRecordDataHeaderShort;

#define SizeOfXLogRecordDataHeaderShort (sizeof(uint8) * 2)

typedef struct XLogRecordDataHeaderLong

{

 uint8 id; /* XLR_BLOCK_ID_DATA_LONG */

 /* followed by uint32 data_length, unaligned */

 //接下来是无符号32位整型的data_length(未对齐)

} XLogRecordDataHeaderLong;

#define SizeOfXLogRecordDataHeaderLong (sizeof(uint8) + sizeof(uint32))

/*

 * Block IDs used to distinguish different kinds of record fragments. Block

 * references are numbered from 0 to XLR_MAX_BLOCK_ID. A rmgr is free to use

 * any ID number in that range (although you should stick to small numbers,

 * because the WAL machinery is optimized for that case). A couple of ID

 * numbers are reserved to denote the "main" data portion of the record.

* 块id用于区分不同类型的记录片段。

* 块引用编号从0到XLR_MAX_BLOCK_ID。

 * rmgr可以自由使用该范围内的任何ID号

 * (尽管您应该坚持使用较小的数字，因为WAL机制针对这种情况进行了优化)。

* 保留两个ID号来表示记录的“main”数据部分。

 *

 * The maximum is currently set at 32, quite arbitrarily. Most records only

 * need a handful of block references, but there are a few exceptions that

 * need more.

* 目前的最大值是32，非常随意。

* 大多数记录只需要少数块引用，但也有少数的例外，需要更多。

 */

#define XLR_MAX_BLOCK_ID 32

#define XLR_BLOCK_ID_DATA_SHORT 255

#define XLR_BLOCK_ID_DATA_LONG 254

#define XLR_BLOCK_ID_ORIGIN 253

#endif /* XLOGRECORD_H */

6) xl_heap_header结构体定义


/*

 * We don't store the whole fixed part (HeapTupleHeaderData) of an inserted

 * or updated tuple in WAL; we can save a few bytes by reconstructing the

 * fields that are available elsewhere in the WAL record, or perhaps just

 * plain needn't be reconstructed. These are the fields we must store.

 * NOTE: t_hoff could be recomputed, but we may as well store it because

 * it will come for free due to alignment considerations.

 * PG不会在WAL中存储插入/更新的元组的全部固定部分(HeapTupleHeaderData);

* 我们可以通过重新构造在WAL记录中可用的一些字段来节省一些空间,或者直接扁平化处理。

* 这些都是我们必须存储的字段。

* 注意:t_hoff可以重新计算，但我们也需要存储它，因为出于对齐的考虑,会被析构。

 */

typedef struct xl_heap_header

{

 uint16 t_infomask2;//t_infomask2标记

 uint16 t_infomask;//t_infomask标记

 uint8 t_hoff;//t_hoff

} xl_heap_header;

//HeapHeader的大小

#define SizeOfHeapHeader (offsetof(xl_heap_header, t_hoff) + sizeof(uint8))

7) xl_heap_insert结构体定义


/*

* xl_heap_insert/xl_heap_multi_insert flag values, 8 bits are available.

*/

/* PD_ALL_VISIBLE was cleared */

#define XLH_INSERT_ALL_VISIBLE_CLEARED (1<<0)

#define XLH_INSERT_LAST_IN_MULTI (1<<1)

#define XLH_INSERT_IS_SPECULATIVE (1<<2)

#define XLH_INSERT_CONTAINS_NEW_TUPLE (1<<3)

/* This is what we need to know about insert */

//这是在插入时需要获知的信息

typedef struct xl_heap_insert

{

//已成功插入的元组的偏移

OffsetNumber offnum; /* inserted tuple's offset */

uint8 flags; //标记

/* xl_heap_header & TUPLE DATA in backup block 0 */

//xl_heap_header & TUPLE DATA在备份块0中

} xl_heap_insert;

//xl_heap_insert大小

#define SizeOfHeapInsert (offsetof(xl_heap_insert, flags) + sizeof(uint8))

四、WAL segment file内容剖析

下面使用linux下的hexdump工具查看WAL文件中的内容，通过查看文件内容可以直观的观察上述的数据结构。

WAL文件信息


[xdb@localhost pg_wal]$ ll

total 32796

-rw-------. 1 xdb xdb 16777216 Dec 18 10:52 000000010000000100000042

...

以下使用000000010000000100000042文件为例进行解析。

1、XLogPageHeaderData

uint16 xlp_magic

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 0 -n 2

00000000 98 d0 |..|

00000002

magic value为0xD098。

注意:X86 CPU使用小端模式(Little-Endian)，高位字节在内存高位地址，低位字节在内存低位地址。

uint16 xlp_info

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 2 -n 2

00000002 07 00 |..|

00000004

xlp_info标志为0x0007,即XLP_FIRST_IS_CONTRECORD | XLP_LONG_HEADER | XLP_BKP_REMOVABLE

表示：

Ø XLOG Record跨越page边界

Ø 这个page的header是XLogLongPageHeaderData

Ø 从该页起始的backup blocks是可选的(不一定存在)

TimeLineID(uint32) xlp_tli

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 4 -n 4

00000004 01 00 00 00 |....|

00000008

TimeLineID为0x00000001,即十进制数值1

XLogRecPtr(uint64) xlp_pageaddr

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 8 -n 8

00000008 00 00 00 42 01 00 00 00 |...B....|

00000010

XLog Record在事务日志指针(偏移)为0x00000001 42000000

uint32 xlp_rem_ln

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 16 -n 4

00000010 0f 00 00 00 |....|

00000014

上一页空间不足以存储XLOG Record,该Record在本页继续存储占用的空间大小:0x0000000F

2、XLogLongPageHeaderData

XLogLongPageHeaderData的第一个字段是XLogPageHeaderData，相关数据参见上述XLogPageHeaderData描述。

注意：XLogPageHeaderData结构体按最大基本类型（unit64）对齐，扩充为24Bytes(原为20Bytes，对齐为8 Bytes的倍数)，因此XLogLongPageHeaderData的内容从偏移24处起算。

uint64 xlp_sysid

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 24 -n 8

00000018 42 72 7f 55 41 76 ee 5b |Br.UAv.[|

00000020

系统标识码0x5BEE7641557F7242

[xdb@localhost ~] $echo$ ((0x5BEE7641557F7242))

6624362124887945794

使用pg_controldata查看Database system identifier-->6624362124887945794

[xdb@localhost ~]$ pg_controldata

pg_control version number: 1100

Catalog version number: 201809051

Database system identifier: 6624362124887945794

...

uint32 xlp_seg_size

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 32 -n 4

00000020 00 00 00 01 |....|

00000024

值为0x01000000,即16M

[xdb@localhost ~] $echo$ ((0x01000000))

16777216

uint32 xlp_xlog_blcksz

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 36 -n 4

00000024 00 20 00 00 |. ..|

00000028

值为0x00002000,即8K

[xdb@localhost ~] $echo$ ((0x00002000))

8192

上一页XLOG Record的剩余部分

由于空间不足，上一page的XLOG Record在本页继续存储占用的空间(xlp_rem_len=0x0F,补齐为16 Bytes)

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 40 -n 16

00000028 31 00 00 00 00 00 00 00 00 69 b8 40 25 00 00 00 |1........i.@%...|

00000038

3、XLogRecord

接下来是XLOG Record中的XLogRecord

uint32 xl_tot_len

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 56 -n 4

00000038 4f 00 00 00 |O...|

0000003c

XLOG Record长度为0x0000004F

TransactionId(uint32) xl_xid

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 60 -n 4

0000003c 6b 07 00 00 |k...|

00000040

事务ID为0x0000076B,即十进制的1899

XLogRecPtr(uint64) xl_pev*

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 64 -n 8

00000040 c0 ff ff 41 01 00 00 00 |...A....|

00000048

上一个XLOG Record的偏移,即0x00000001 41FFFFC0

unit8 xl_info

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 72 -n 1

00000048 00 |.|

00000049

标志位为0x00

unit8 xl_rmid

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 73 -n 1

00000049 0a |.|

0000004a

该记录的资源管理器,即0x0A

2 bytes of padding

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 74 -n 2

0000004a 00 00 |..|

0000004c

pg_crc32c(uint32) xl_crc

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 76 -n 4

0000004c ea 21 d2 50 |.!.P|

00000050

CRC校验位,即0x50D221EA

4、XLOG Record data

XLogRecord之后是XLOG Record中的XLOG Record data

1) XLogRecordBlockHeader

uint8 id

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 80 -n 1

00000050 00 |.|

00000051

块引用ID为0x00,即0号Block.

uint8 fork_flags

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 81 -n 1

00000051 20 | |

00000052

值为0x20,高4位用于标记,即BKPBLOCK_HAS_DATA

uint16 data_length

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 82 -n 2

00000052 1e 00 |..|

00000054

payload bytes = 0x001E,十进制数值为30.

RelFileNode

接下来是RelFileNode，包括tablespace/database/relation，均为Oid类型(unsigned int)。

Ø tablespace

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 84 -n 4

00000054 7f 06 00 00 |....|

00000058

值为0x0000067F,十进制值为1663

表空间为default

testdb=# select * from pg_tablespace where oid=1663;

spcname | spcowner | spcacl | spcoptions

------------+----------+--------+------------

pg_default | 10 | |

(1 row)

Ø database

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 88 -n 4

00000058 12 40 00 00 |.@..|

0000005c

值为0x00004012,十进制值为16402,数据库为testdb

testdb=# select * from pg_database where oid=16402;

nxid | datminmxid | dattablespace | datacl

---------+--------+----------+------------+----------+---------------+--------------+--------------+---------------+---------

-----+------------+---------------+--------

testdb | 10 | 6 | C | C | f | t | -1 | 13284 |

561 | 1 | 1663 |

(1 row)

Ø relation

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 92 -n 4

0000005c 56 42 00 00 |VB..|

00000060

值为0x00004256,十进制值为16982

testdb=# select oid,relfilenode,relname from pg_class where relfilenode = 16982;

oid | relfilenode | relname

-------+-------------+---------

16982 | 16982 | t_jfxx

(1 row)

相应的关系为t_jfxx

BlockNumber

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 96 -n 4

00000060 85 00 00 00 |....|

00000064

值为0x00000085,十进制值为133,这是对应的数据块号.

2) XLogRecordDataHeaderShort

接下来是XLogRecordDataHeaderShort/Long,由于数据小于256B,使用XLogRecordDataHeaderShort结构

unit8 id

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 100 -n 1

00000064 ff |.|

00000065

值为0xFF --> XLR_BLOCK_ID_DATA_SHORT 255

uint8 data_length

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 101 -n 1

00000065 03 |.|

00000066

值为0x03,3个字节,指的是main data的大小,3个字节是xl_heap_insert结构体的大小.

3) block data

XLogRecordDataHeaderShort之后是block data，由两部分组成：

Ø xl_heap_header

Ø Tuple data

xl_heap_header

Ø uint16 t_infomask2

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 102 -n 2

00000066 03 00 |..|

00000068

t_infomask2值为0x03,二进制值为00000000 00000011

Ø uint16 t_infomask

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 104 -n 2

00000068 02 08 |..|

0000006a

t_infomask值为0x0802,二进制值为00001000 00000010

Ø uint8 t_hoff

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 106 -n 1

0000006a 18 |.|

0000006b

t_hoff值(偏移)为0x18,十进制值为24

Tuple data

该部分的大小为25 Bytes：

XLOG Record的大小是0x4F即79 Bytes，减去XLogRecord(24 Bytes) + XLogRecordBlockHeader(20 Bytes) + XLogRecordDataHeaderShort(2 Bytes) + xl_heap_header(5 Bytes) + main data(3 Bytes)，剩余空间大小为25 Bytes。

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 107 -n 25

0000006b 00 0d 32 30 39 31 39 0f 32 30 31 33 30 37 00 00 |..20919.201307..|

0000007b 00 00 00 00 00 00 03 b3 40 |........@|

00000084

4) main data

这部分存储的是xl_heap_insert结构体

uint16 OffsetNumber

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 132 -n 2

00000084 26 00 |&.|

00000086

插入的tuple的偏移为0x0026,十进制为38

uint8 flags

[xdb@localhost pg_wal]$ hexdump -C 000000010000000100000042 -s 134 -n 1

00000086 00 |.|

00000087

标志位为0x00

五、pg_waldump工具简介

按照上面几节对事务日志文件结构的介绍，可以自行写一个解析事务日志的小程序用于查看日志文件中的内容，PG已提供了dump事务日志的工具：pg_waldump（PG 9.x或以下版本，使用pg_xlogdump）。

在Linux下执行，使用--help查看帮助信息。

[xdb@localhost pg_wal]$ pg_waldump --help

pg_waldump decodes and displays PostgreSQL write-ahead logs for debugging.

Usage:

pg_waldump [OPTION]... [STARTSEG [ENDSEG]]

Options:

-b, --bkp-details output detailed information about backup blocks

…

各选项的详细解释可参加PG Document。

下面以举例的方式简单介绍该工具的使用。

[xdb@localhost pg_wal]$ ll

total 98332

-rw-------. 1 xdb xdb 16777216 Dec 20 12:02 000000010000000100000048

-rw-------. 1 xdb xdb 16777216 Dec 19 16:47 000000010000000100000049

-rw-------. 1 xdb xdb 16777216 Dec 19 16:47 00000001000000010000004A

-rw-------. 1 xdb xdb 16777216 Dec 19 16:47 00000001000000010000004B

-rw-------. 1 xdb xdb 16777216 Dec 19 16:47 00000001000000010000004C

-rw-------. 1 xdb xdb 16777216 Dec 19 16:47 00000001000000010000004D

drwx------. 2 xdb xdb 6 Nov 16 15:48 archive_status

以上为数据库服务器上的事务日志文件。

例一：查看000000010000000100000048最早的4个XLOG Record

命令：pg_waldump -p ./ -s 1/48000000 -n 4

[xdb@localhost pg_wal]$ pg_waldump -p ./ -s 1/48000000 -n 4

rmgr: Heap len (rec/tot): 77/ 77, tx: 1964, lsn: 1/48000070, prev 1/47FFFFF8, desc: INSERT off 117, blkref #0: rel 1663/16402/17028 blk 1110

rmgr: Heap len (rec/tot): 77/ 77, tx: 1964, lsn: 1/480000C0, prev 1/48000070, desc: INSERT off 7, blkref #0: rel 1663/16402/17031 blk 1111

rmgr: Heap len (rec/tot): 77/ 77, tx: 1964, lsn: 1/48000110, prev 1/480000C0, desc: INSERT off 8, blkref #0: rel 1663/16402/17031 blk 1111

rmgr: Heap len (rec/tot): 77/ 77, tx: 1964, lsn: 1/48000160, prev 1/48000110, desc: INSERT off 9, blkref #0: rel 1663/16402/17031 blk 1111

注意第一条记录，上一个LSN为1/47FFFFF8(prev 1/47FFFFF8)，表示上一page最后一个XLOG Record存储在本页的XLogLongPageHeaderData中，存储的空间大小可以从该XLOG Record的LSN(1/48000070)和XLogLongPageHeaderData的大小(40 Bytes)推算而得。

例二：查看Redo point后的XLOG Record

首先使用pg_controldata命令查看Redo point --> 1/484336A0


 [xdb@localhost pg_wal]$ pg_controldata

pg_control version number: 1100

Catalog version number:              201809051

Database system identifier: 6624362124887945794

Database cluster state: in production

pg_control last modified: Thu 20 Dec 2018 12:17:39 PM CST

Latest checkpoint location: 1/484336D8

Latest checkpoint's REDO location: 1/484336A0

Latest checkpoint's REDO WAL file: 000000010000000100000048

Latest checkpoint's TimeLineID: 1

...

然后使用pg_waldump查看

命令：pg_waldump -p ./ -s 1/484336A0


 [xdb@localhost pg_wal]$ pg_waldump -p ./ -s 1/484336A0

rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 1/484336A0, prev 1/48433668, desc: RUNNING_XACTS nextXid 1971 latestCompletedXid 1970 oldestRunningXid 1971

rmgr: XLOG len (rec/tot): 106/ 106, tx: 0, lsn: 1/484336D8, prev 1/484336A0, desc: CHECKPOINT_ONLINE redo 1/484336A0; tli 1; prev tli 1; fpw true; xid 0:1971; oid 17046; multi 1; offset 0; oldest xid 561 in DB 16402; oldest multi 1 in DB 16402; oldest/newest commit timestamp xid: 0/0; oldest running xid 1971; online

rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 1/48433748, prev 1/484336D8, desc: RUNNING_XACTS nextXid 1971 latestCompletedXid 1970 oldestRunningXid 1971

pg_waldump: FATAL: error in WAL record at 1/48433748: invalid record length at 1/48433780: wanted 24, got 0

[xdb@localhost pg_wal]$

六、参考资料

1、Write Ahead Logging — WAL
2、PG Source Code
3、WAL Internals Of PostgreSQL
4、关于结构体占用空间大小总结
 5、PG 11 Document

PostgreSQL 事务日志WAL结构浅析

摘要

一、WAL基本术语

二、WAL文件组成

1、WAL segment file

2、再谈LSN

三、WAL segment file内部结构

1、WAL segment file

2、XLOG Record

3、数据结构

四、WAL segment file内容剖析

1、XLogPageHeaderData

2、XLogLongPageHeaderData

3、XLogRecord

4、XLOG Record data

五、pg_waldump工具简介

六、参考资料

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

程序员

PostgreSQL