PG wal 日志的物理存储分析
原文链接：http://www.postgres.cn/v2/news/viewone/1/385?tdsourcetag=s_pcqq_aiomsg
我做人很厚道的。 必须留下链接。
感谢原作者的分享。
PostgreSQL 事务日志WAL探秘（上篇）
原作者：何小栋（EthanHE） 创作时间：2019-01-02 09:03:46+08 采编：redraiment
发布时间：2019-01-02 09:03:46
欢迎大家踊跃投稿，投稿信箱：press@postgres.cn
评论：浏览：234
摘要事务日志是数据库的重要组成部分，存储了数据库系统中所有更改和操作的历史，以确保数据库不会因为故障(例如掉电或其他导致服务器崩溃的故障)而丢失数据。在PostgreSQL(以下简称PG)中，事务日志文件称为Write Ahead Log（以下简称WAL）。
本文对PG中事务日志文件的结构进行了简要的剖析，内容包括WAL基本术语、WAL文件组成、WAL segment file内部结构和内容剖析、XLOG Record内存组织以及pg_waldump工具简介。本篇是第一部分，内容包括WAL基本术语、WAL文件组成以及WAL segment file的内部结构。
为了更好的理解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查看该文件中的内容。
如前所述，事务日志存储了数据库系统中所有更改和操作的历史，随着数据库的运行，事务日志大小不断的增长，那么事务日志有大小限制吗？在PG中，答案是肯定的：大小有限制。
PG使用无符号64bit整型（uint64）作为事务日志文件的寻址空间，理论上，PG的事务日志空间最大为2^64Bytes(即16EB)。这个大小有多大呢？假设某个数据库比较繁忙，每天可以产生16TB的日志文件，那么要达到事务日志文件大小的上限需要的时间是1024*1024/365天≈2800年。也就是说，虽然大小有限制，但从现阶段来看已然足够了。
显然，对于16EB的文件，OS是无法高效管理的，为此，PG把事务日志文件划分为N个大小为16M(默认值)的WAL segment file，其总体结构如下图所示：
图一 事务日志总体结构
1、WAL segment fileWAL 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的unit816M的文件大小是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=#SELECTpg_walfile_name('1/4288E228');pg_walfile_name--------------------------000000010000000100000042(1row)三、WAL segment file内部结构
WAL segment file默认大小为16MB,其内部结构如下图所示：
图二 WAL segment file内部结构
1、WAL segment fileWAL 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 RecordXLOG Record由两部分组成，第一部分是XLOG Record的头部信息，大小固定（24 Bytes），对应的结构体是XLogRecord；第二部分是XLOG Record data。
XLOG Record的整体布局如下:
头部数据(固定大小的XLogRecord结构体)XLogRecordBlockHeader结构体XLogRecordBlockHeader结构体...XLogRecordDataHeader[Short|Long]结构体blockdatablockdata...maindata
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结构体定义
/**EachpageofXLOGfilehasaheaderlikethis:*每一个事务日志文件的page都有头部信息,结构如下:*///可作为WAL版本信息#defineXLOG_PAGE_MAGIC0xD098/*canbeusedasWALversionindicator*/typedefstructXLogPageHeaderData{//WAL版本信息,PGV11.1-->0xD98uint16xlp_magic;/*magicvalueforcorrectnesschecks*///标记位(详见下面说明)uint16xlp_info;/*flagbits,seebelow*///page中第一个XLOGRecord的TimeLineID,类型为uint32TimeLineIDxlp_tli;/*TimeLineIDoffirstrecordonpage*///page的XLOG地址(在事务日志中的偏移),类型为uint64XLogRecPtrxlp_pageaddr;/*XLOGaddressofthispage*//**Whenthereisnotenoughspaceoncurrentpageforwholerecord,we*continueonthenextpage.xlp_rem_lenisthenumberofbytes*remainingfromapreviouspage.*如果当前页的空间不足以存储整个XLOGRecord,在下一个页面中存储余下的数据*xlp_rem_len表示上一页XLOGRecord剩余部分的大小**Notethatxl_rem_lenincludesbackup-blockdata;thatis,ittracks*xl_tot_lennotxl_lenintheinitialheader.Alsonotethatthe*continuationdataisn'tnecessarilyaligned.*注意xl_rem_len包含backup-blockdata(full-page-write);*也就是说在初始的头部信息中跟踪的是xl_tot_len而不是xl_len.*另外要注意的是剩余的数据不需要对齐.*///上一页空间不够存储XLOGRecord,该Record在本页继续存储占用的空间大小uint32xlp_rem_len;/*totallenofremainingdataforrecord*/}XLogPageHeaderData;#defineSizeOfXLogShortPHDMAXALIGN(sizeof(XLogPageHeaderData))typedefXLogPageHeaderData*XLogPageHeader;
2、XLogLongPageHeaderData结构体定义
/**WhentheXLP_LONG_HEADERflagisset,westoreadditionalfieldsinthe*pageheader.(Thisisordinarilydonejustinthefirstpageofan*XLOGfile.)Theadditionalfieldsservetoidentifythefileaccurately.*如设置了XLP_LONG_HEADER标记,在pageheader中存储额外的字段.*(通常在每个事务日志文件也就是segmentfile的的第一个page中存在).*附加字段用于准确识别文件。*/typedefstructXLogLongPageHeaderData{//标准的头部域字段XLogPageHeaderDatastd;/*standardheaderfields*///pg_control中的系统标识码uint64xlp_sysid;/*systemidentifierfrompg_control*///交叉检查uint32xlp_seg_size;/*justasacross-check*///交叉检查uint32xlp_xlog_blcksz;/*justasacross-check*/}XLogLongPageHeaderData;#defineSizeOfXLogLongPHDMAXALIGN(sizeof(XLogLongPageHeaderData))//指针typedefXLogLongPageHeaderData*XLogLongPageHeader;/*Whenrecordcrossespageboundary,setthisflaginnewpage'sheader*///如果XLOGRecord跨越page边界,在新pageheader中设置该标志位#defineXLP_FIRST_IS_CONTRECORD0x0001//该标志位标明是"long"页头/*Thisflagindicatesa"long"pageheader*/#defineXLP_LONG_HEADER0x0002/*Thisflagindicatesbackupblocksstartinginthispageareoptional*///该标志位标明从该页起始的backupblocks是可选的(不一定存在)#defineXLP_BKP_REMOVABLE0x0004//xlp_info中所有定义的标志位(用于pageheader的有效性检查)/*Alldefinedflagbitsinxlp_info(usedforvaliditycheckingofheader)*/#defineXLP_ALL_FLAGS0x0007#defineXLogPageHeaderSize(hdr)\(((hdr)->xlp_info&XLP_LONG_HEADER)?SizeOfXLogLongPHD:SizeOfXLogShortPHD)
3、XLogRecord结构体定义
/**TheoveralllayoutofanXLOGrecordis:*Fixed-sizeheader(XLogRecordstruct)*XLogRecordBlockHeaderstruct*XLogRecordBlockHeaderstruct*...*XLogRecordDataHeader[Short|Long]struct*blockdata*blockdata*...*maindata*XLOGrecord的整体布局如下:*固定大小的头部(XLogRecord结构体)*XLogRecordBlockHeader结构体*XLogRecordBlockHeader结构体*...*XLogRecordDataHeader[Short|Long]结构体*blockdata*blockdata*...*maindata**TherecanbezeroormoreXLogRecordBlockHeaders,and0ormorebytesof*rmgr-specificdatanotassociatedwithablock.XLogRecordstructs*alwaysstartonMAXALIGNboundariesintheWALfiles,buttherestof*thefieldsarenotaligned.*其中,XLogRecordBlockHeaders可能有0或者多个,与block无关的0或多个字节的rmgr-specific数据*XLogRecord通常在WAL文件的MAXALIGN边界起写入,但后续的字段并没有对齐**TheXLogRecordBlockHeader,XLogRecordDataHeaderShortand*XLogRecordDataHeaderLongstructsallbeginwithasingle'id'byte.It's*usedtodistinguishbetweenblockreferences,andthemaindatastructs.*XLogRecordBlockHeader/XLogRecordDataHeaderShort/XLogRecordDataHeaderLong开头是占用1个字节的"id".*用于区分block依赖和maindata结构体.*/typedefstructXLogRecord{//record的大小uint32xl_tot_len;/*totallenofentirerecord*///xactidTransactionIdxl_xid;/*xactid*///指向log中的前一条记录XLogRecPtrxl_prev;/*ptrtopreviousrecordinlog*///标识位,详见下面的说明uint8xl_info;/*flagbits,seebelow*///该记录的资源管理器RmgrIdxl_rmid;/*resourcemanagerforthisrecord*//*2bytesofpaddinghere,initializetozero*///2个字节的crc校验位,初始化为0pg_crc32cxl_crc;/*CRCforthisrecord*//*XLogRecordBlockHeadersandXLogRecordDataHeaderfollow,nopadding*///接下来是XLogRecordBlockHeaders和XLogRecordDataHeader}XLogRecord;//宏定义:XLogRecord大小#defineSizeOfXLogRecord(offsetof(XLogRecord,xl_crc)+sizeof(pg_crc32c))/**Thehigh4bitsinxl_infomaybeusedfreelybyrmgr.The*XLR_SPECIAL_REL_UPDATEandXLR_CHECK_CONSISTENCYbitscanbepassedby*XLogInsertcaller.TherestaresetinternallybyXLogInsert.*xl_info的高4位由rmgr自由使用.*XLR_SPECIAL_REL_UPDATE和XLR_CHECK_CONSISTENCY由XLogInsert函数的调用者传入.*其余由XLogInsert内部使用.*/#defineXLR_INFO_MASK0x0F#defineXLR_RMGR_INFO_MASK0xF0/**IfaWALrecordmodifiesanyrelationfiles,inwaysnotcoveredbythe*usualblockreferences,thisflagisset.Thisisnotusedforanything*byPostgreSQLitself,butitallowsexternaltoolsthatreadWALandkeep*trackofmodifiedblockstorecognizesuchspecialrecordtypes.*如果WAL记录使用特殊的方式(不涉及通常块引用)更新了关系的存储文件,设置此标记.*PostgreSQL本身并不使用这种方法，但它允许外部工具读取WAL并跟踪修改后的块，*以识别这种特殊的记录类型。*/#defineXLR_SPECIAL_REL_UPDATE0x01/**EnforcesconsistencychecksofreplayedWALatrecovery.Ifenabled,*eachrecordwilllogafull-pagewriteforeachblockmodifiedbythe*recordandwillreuseitafterwardsforconsistencychecks.Thecaller*ofXLogInsertcanusethisvalueifnecessary,butif*wal_consistency_checkingisenabledforarmgrthisissetunconditionally.*在恢复时强制执行一致性检查.*如启用此功能,每个记录将为记录修改的每个块记录一个完整的页面写操作，并在以后重用它进行一致性检查。*在需要时,XLogInsert的调用者可使用此标记,但如果rmgr启用了wal_consistency_checking,*则会无条件执行一致性检查.*/#defineXLR_CHECK_CONSISTENCY0x02
4、XLogRecordBlockHeader结构体定义
/**HeaderinfoforblockdataappendedtoanXLOGrecord.*追加到XLOGrecord中blockdata的头部信息**'data_length'isthelengthofthermgr-specificpayloaddataassociated*withthisblock.Itdoesnotincludethepossiblefullpageimage,nor*XLogRecordBlockHeaderstructitself.*'data_length'是与此块关联的rmgr特定payloaddata的长度。*它不包括可能的fullpageimage，也不包括XLogRecordBlockHeader结构体本身。**Notethatwedon'tattempttoaligntheXLogRecordBlockHeaderstruct!*So,thestructmustbecopiedtoalignedlocalstoragebeforeuse.*注意:我们不打算尝试对齐XLogRecordBlockHeader结构体!*因此,在使用前,XLogRecordBlockHeader必须拷贝到对齐的本地存储中.*/typedefstructXLogRecordBlockHeader{//块引用IDuint8id;/*blockreferenceID*///在关系中使用的fork和flagsuint8fork_flags;/*forkwithintherelation,andflags*///payload字节大小uint16data_length;/*numberofpayloadbytes(notincludingpage*image)*//*IfBKPBLOCK_HAS_IMAGE,anXLogRecordBlockImageHeaderstructfollows*//*IfBKPBLOCK_SAME_RELisnotset,aRelFileNodefollows*//*BlockNumberfollows*///如BKPBLOCK_HAS_IMAGE,后续为XLogRecordBlockImageHeader结构体//如BKPBLOCK_SAME_REL没有设置,则为RelFileNode//后续为BlockNumber}XLogRecordBlockHeader;#defineSizeOfXLogRecordBlockHeader(offsetof(XLogRecordBlockHeader,data_length)+sizeof(uint16))
5、XLogRecordDataHeader[Short|Long]结构体定义
/**XLogRecordDataHeaderShort/Longareusedforthe"maindata"portionof*therecord.Ifthelengthofthedataislessthan256bytes,theshort*formisused,withasinglebytetoholdthelength.Otherwisethelong*formisused.*XLogRecordDataHeaderShort/Long用于记录的“maindata”部分。*如果数据的长度小于256字节，则使用短格式，用一个字节保存长度。*否则使用长形式。**(Thesestructsarecurrentlynotusedinthecode,theyareherejustfor*documentationpurposes).*(这些结构体不会再代码中使用,在这里是为了文档记录的目的)*/typedefstructXLogRecordDataHeaderShort{uint8id;/*XLR_BLOCK_ID_DATA_SHORT*/uint8data_length;/*numberofpayloadbytes*/}XLogRecordDataHeaderShort;#defineSizeOfXLogRecordDataHeaderShort(sizeof(uint8)*2)typedefstructXLogRecordDataHeaderLong{uint8id;/*XLR_BLOCK_ID_DATA_LONG*//*followedbyuint32data_length,unaligned*///接下来是无符号32位整型的data_length(未对齐)}XLogRecordDataHeaderLong;#defineSizeOfXLogRecordDataHeaderLong(sizeof(uint8)+sizeof(uint32))/**BlockIDsusedtodistinguishdifferentkindsofrecordfragments.Block*referencesarenumberedfrom0toXLR_MAX_BLOCK_ID.Armgrisfreetouse*anyIDnumberinthatrange(althoughyoushouldsticktosmallnumbers,*becausetheWALmachineryisoptimizedforthatcase).AcoupleofID*numbersarereservedtodenotethe"main"dataportionoftherecord.*块id用于区分不同类型的记录片段。*块引用编号从0到XLR_MAX_BLOCK_ID。*rmgr可以自由使用该范围内的任何ID号*(尽管您应该坚持使用较小的数字，因为WAL机制针对这种情况进行了优化)。*保留两个ID号来表示记录的“main”数据部分。**Themaximumiscurrentlysetat32,quitearbitrarily.Mostrecordsonly*needahandfulofblockreferences,butthereareafewexceptionsthat*needmore.*目前的最大值是32，非常随意。*大多数记录只需要少数块引用，但也有少数的例外，需要更多。*/#defineXLR_MAX_BLOCK_ID32#defineXLR_BLOCK_ID_DATA_SHORT255#defineXLR_BLOCK_ID_DATA_LONG254#defineXLR_BLOCK_ID_ORIGIN253#endif/*XLOGRECORD_H*/
6、xl_heap_header结构体定义
/**Wedon'tstorethewholefixedpart(HeapTupleHeaderData)ofaninserted*orupdatedtupleinWAL;wecansaveafewbytesbyreconstructingthe*fieldsthatareavailableelsewhereintheWALrecord,orperhapsjust*plainneedn'tbereconstructed.Thesearethefieldswemuststore.*NOTE:t_hoffcouldberecomputed,butwemayaswellstoreitbecause*itwillcomeforfreeduetoalignmentconsiderations.*PG不会在WAL中存储插入/更新的元组的全部固定部分(HeapTupleHeaderData);*我们可以通过重新构造在WAL记录中可用的一些字段来节省一些空间,或者直接扁平化处理。*这些都是我们必须存储的字段。*注意:t_hoff可以重新计算，但我们也需要存储它，因为出于对齐的考虑,会被析构。*/typedefstructxl_heap_header{uint16t_infomask2;//t_infomask2标记uint16t_infomask;//t_infomask标记uint8t_hoff;//t_hoff}xl_heap_header;//HeapHeader的大小#defineSizeOfHeapHeader(offsetof(xl_heap_header,t_hoff)+sizeof(uint8))7)xl_heap_insert结构体定义/**xl_heap_insert/xl_heap_multi_insertflagvalues,8bitsareavailable.*//*PD_ALL_VISIBLEwascleared*/#defineXLH_INSERT_ALL_VISIBLE_CLEARED(1<<0)#defineXLH_INSERT_LAST_IN_MULTI(1<<1)#defineXLH_INSERT_IS_SPECULATIVE(1<<2)#defineXLH_INSERT_CONTAINS_NEW_TUPLE(1<<3)/*Thisiswhatweneedtoknowaboutinsert*///这是在插入时需要获知的信息typedefstructxl_heap_insert{//已成功插入的元组的偏移OffsetNumberoffnum;/*insertedtuple'soffset*/uint8flags;//标记/*xl_heap_header&TUPLEDATAinbackupblock0*///xl_heap_header&TUPLEDATA在备份块0中}xl_heap_insert;//xl_heap_insert大小#defineSizeOfHeapInsert(offsetof(xl_heap_insert,flags)+sizeof(uint8))四、参考资料Write Ahead Logging — WAL：http://www.interdb.jp/pg/pgsql09.htmlPG Source Code：https://doxygen.postgresql.orgWAL Internals Of PostgreSQL：https://www.pgcon.org/2012/schedule/attachments/258_212_Internals%20Of%20PostgreSQL%20Wal.pdf关于结构体占用空间大小总结：https://blog.csdn.net/Netown_Ethereal/article/details/38898003PG 11 Document：https://www.postgresql.org/docs/11/pgwaldump.html
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
