PgSQL · 特性分析 · 数据库崩溃恢复（下）

背景

在上期月报PgSQL · 特性分析 · 数据库崩溃恢复（上），我们分析了PostgreSQL在数据库非正常退出后（包括通过recovery.conf用户主动恢复）的处理，概括起来分为以下几步：

1.如果满足以下条件之一，则进行非正常退出恢复

• pg_control文件中的数据库状态不正常（非DB_SHUTDOWNED）
• pg_control文件中记录的最新检查点读取不到XLOG日志文件

2.用户指定recovery.conf文件主动恢复
3.根据pg_control、backup_label确定恢复的XLOG日志记录起点
不断读取每个XLOG record，根据所属的资源管理器去调用各自：

• rm_startup()
• rm_redo(EndRecPtr, record)
• rm_cleanup();

4.不断恢复XLOG日志记录，直到满足以下条件之一，则停止恢复正常启动

• 达到recovery.conf文件中规定的最终的目标恢复位点
• 当前XLOG日志全部应用完成

5.清理环境，并启动需要的辅助进程
其中，PostgreSQL会根据每个XLOG record所属的资源管理器操作来执行对应的函数。PostgreSQL中有以下的资源管理器：

RM_XLOG_ID
RM_XACT_ID
RM_SMGR_ID
RM_CLOG_ID
RM_DBASE_ID
RM_TBLSPC_ID
RM_MULTIXACT_ID
RM_RELMAP_ID
RM_STANDBY_ID
RM_HEAP2_ID
RM_HEAP_ID
RM_BTREE_ID
RM_HASH_ID
RM_GIN_ID
RM_GIST_ID
RM_SEQ_ID
RM_SPGIST_ID

而每种资源管理器，都存在几种具体的操作，例如RM_HEAP_ID包括以下操作（后面的数字代表对应XLogRecord中xl_info字段高4位，详情参考上期月报）：

#define XLOG_HEAP_INSERT        0x00
#define XLOG_HEAP_DELETE        0x10
#define XLOG_HEAP_UPDATE        0x20
/* 0x030 is free, was XLOG_HEAP_MOVE */
#define XLOG_HEAP_HOT_UPDATE    0x40
#define XLOG_HEAP_NEWPAGE        0x50
#define XLOG_HEAP_LOCK            0x60
#define XLOG_HEAP_INPLACE        0x70

下面我们将以堆表的INSERT操作为例，具体分析对应的XLOG record内容和资源管理器对应的处理函数。
**XLOG record
XLOG record 结构**
在PgSQL · 特性分析 · 数据库崩溃恢复（上）中，分析了WAL日志页的基本结构。其中，一条日志记录的的组织形式如下所示（以下分析基于RDS for PostgreSQL，即9.4版本）:

*        Fixed-size header (XLogRecord struct) /*日志记录头*/
 *        rmgr-specific data /*资源管理器数据，对应操作的对象，譬如元组的id等内容*/
 *        BkpBlock/*备份块块头*/
 *        backup block data/*操作的一些数据，如更新元组时，要更新的新值存储在这个区域*/
 *        BkpBlock
 *        backup block data
 *        ...

为了更好地探究堆表INSERT操作对应XLOG record 的内容，我们创建一个简单的TABLE，并执行INSERT操作：

create table test(id int);
insert into test values(3);

XLogInsert函数
在执行INSERT操作的时候，PostgreSQL会调用heap_insert函数，其中会调用XLogInsert去插入对应的XLOG record：

recptr = XLogInsert(RM_HEAP_ID, info, rdata);
PageSetLSN(page, recptr);

注意：实际上是调用两次XLogInsert，除了HEAP INSERT操作的XLOG record，还有事务提交的XLOG record。

函数XLogInsert的返回值是XLogRecPtr结构类型，即LSN（log secquence number）。heap_insert函数在执行XLogInsert()后，把其返回值XLogRecPtr记录赋值给对应的page的PageHeaderData结构中，以实现WAL机制（参考PgSQL · 特性分析 · Write-Ahead Logging机制浅析）。

XLogInsert函数中会去包装一个XLOG record，并把它刷写到磁盘，我们接下来分析一下XLogInsert函数。

XLogInsert函数定义：

XLogRecPtr XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)

XLogInsert的三个函数参数分别是：

• rmid
  1.RmgrId类型

2.代表本条XLOG record所属的资源管理器类型，例如我们上面的例子中INSERT操作属于RM_HEAP_ID，即堆表资源管理器

• info
  1.uint8类型

2.代表资源管理器对应的操作，例如堆表中INSERT操作为0x00

• rdata
  1.XLogRecData指针类型（链表）

2.每个XLogRecData结构体存储对应的资源管理器数据rmgr-specific data

之所以要用XLogRecData链，是因为在所要处理的日志记录实体数据在内存空间可能不是连续存储的，而且数据可能分布在多个缓冲区内，需要用XlogRecData链表将它们组织起来。XlogRecData数据结构如下：

typedef struct XLogRecData
{
    char       *data;    /*包含实体数据的起始位置*/
    uint32        len;        /*包含实体数据大小*/
    Buffer        buffer;    /*如果有buffer指明第几个缓冲区*/
    bool        buffer_std;    /*是否含有标准的pd_lower/pd_upper结构*/
    struct XLogRecData *next;    /*指向下一个XLogRecData*/
} XLogRecData;

其中，buffer_std该值为true，则容许XLOG释放备份页的空闲空间，空闲空间由pd_lower和pd_upper限定：

• pd_lower表示页面起始位置与未分配空间开头的字节偏移
• pd_upper表示页面末尾位置与未分配空间末尾的字节偏移
  通过分析三个XLogInsert函数参数，可以看出XLogInsert主要是将rdata封装成一个XLOG record。接下来我们将分析heap_insert函数内如何对rdata进行赋值。

heap_insert函数

heap_insert函数主要操作HeapTupleData结构体，对应在每个数据页中存储的每个tuple，结构如下图所示：

tuple分为头部信息和数据信息，这里不再展开，我们将在分析PostgreSQL的MVCC机制时，将其中的结构详细分析。

heap_insert函数的主要操作如下：

• 调用RelationGetBufferForTuple方法找到shmem里缓存数据块buffer
• 调用RelationPutHeapTuple方法，把组装好的元组tuple放到对应buffer中合适的位置
• 赋值XLogRecData类型变量rdata，通过代码分析可以看出rdata实际上是对tuple的内容摘要
• XLogRecData rdata[4]; 堆表的INSERT操作有4个XLogRecData结构体组成的链表
• rdata[0].data 存储一个xl_heap_insert结构，用于标示一些基本信息：

/* This is what we need to know about insert */
typedef struct xl_heap_insert
{
    xl_heaptid    target;            /* inserted tuple id */
    uint8        flags;
    /* xl_heap_header & TUPLE DATA FOLLOWS AT END OF STRUCT */
} xl_heap_insert;

• rdata[0].buffer = InvalidBuffer
• rdata[1].data存储一个xl_heap_header结构，存储tuple头部的简化信息：

typedef struct xl_heap_header
{
    uint16        t_infomask2;
    uint16        t_infomask;
    uint8        t_hoff;
} xl_heap_header;

• rdata[1].buffer = need_tuple_data ? InvalidBuffer : buffer;如果需要存储整个数据块，则把buffer赋值给rdata
• rdata[2].data存储tuple头部后面的数据，比如INSERT操作的插入元组的每列的数值
• rdata[2].buffer = need_tuple_data ? InvalidBuffer : buffer;同rdata[1]
• 如果需要存储整个数据块，则rdata[3].buffer=buffer
• 调用XLogInsert，将rdata封装成XLOG record写入WAL缓冲区，如果需要切换日志段文件，调用XLogWrite刷写到磁盘

经过以上分析，我们可以知道，XLOG record的核心部分是资源管理器数据（XLogRecData）和备份数据块（backup block data），这两个数据包含了我们恢复时候需要的数据。在各个资源管理器的具体操作调用XLogInsert之前，需要对这两个部分进行填充。

资源管理器对应处理函数

资源管理器结构

在恢复过程中，每个资源管理器对应的处理函数是不同的，为了更好的抽象资源管理器，在PostgreSQL中定义了RmgrData结构体和一个RmgrData类型数组RmgrTable。

typedef struct RmgrData
{
    const char *rm_name;
    void        (*rm_redo) (XLogRecPtr lsn, struct XLogRecord *rptr);
    void        (*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
    void        (*rm_startup) (void);
    void        (*rm_cleanup) (void);
} RmgrData;
extern const RmgrData RmgrTable[];
PG_RMGR(RM_XLOG_ID, "XLOG", xlog_redo, xlog_desc, NULL, NULL)
PG_RMGR(RM_XACT_ID, "Transaction", xact_redo, xact_desc, NULL, NULL)
PG_RMGR(RM_SMGR_ID, "Storage", smgr_redo, smgr_desc, NULL, NULL)
PG_RMGR(RM_CLOG_ID, "CLOG", clog_redo, clog_desc, NULL, NULL)
PG_RMGR(RM_DBASE_ID, "Database", dbase_redo, dbase_desc, NULL, NULL)
PG_RMGR(RM_TBLSPC_ID, "Tablespace", tblspc_redo, tblspc_desc, NULL, NULL)
PG_RMGR(RM_MULTIXACT_ID, "MultiXact", multixact_redo, multixact_desc, NULL, NULL)
PG_RMGR(RM_RELMAP_ID, "RelMap", relmap_redo, relmap_desc, NULL, NULL)
PG_RMGR(RM_STANDBY_ID, "Standby", standby_redo, standby_desc, NULL, NULL)
PG_RMGR(RM_HEAP2_ID, "Heap2", heap2_redo, heap2_desc, NULL, NULL)
PG_RMGR(RM_HEAP_ID, "Heap", heap_redo, heap_desc, NULL, NULL)
PG_RMGR(RM_BTREE_ID, "Btree", btree_redo, btree_desc, NULL, NULL)
PG_RMGR(RM_HASH_ID, "Hash", hash_redo, hash_desc, NULL, NULL)
PG_RMGR(RM_GIN_ID, "Gin", gin_redo, gin_desc, gin_xlog_startup, gin_xlog_cleanup)
PG_RMGR(RM_GIST_ID, "Gist", gist_redo, gist_desc, gist_xlog_startup, gist_xlog_cleanup)
PG_RMGR(RM_SEQ_ID, "Sequence", seq_redo, seq_desc, NULL, NULL)
PG_RMGR(RM_SPGIST_ID, "SPGist", spg_redo, spg_desc, spg_xlog_startup, spg_xlog_cleanup)

• RmgrTable的下标对应上文提到的资源管理器ID，比如HEAP表对应的RmgrData是RmgrTable[RM_HEAP_ID]。
• RmgrData中定义了rm_redo、rm_desc、rm_startup、rm_cleanup四个函数指针，分别对应每个资源管理器具体的redo、desc、startup、cleanup函数，我们主要分析下其中的rm_redo恢复函数

REDO函数

不同资源管理器的REDO函数参数都为（XLogRecPtr lsn, XLogRecord *record），这两个类型的参数我们在前面两期月报中均有涉及。其中：

• XLogRecPtr类型代表着该log record在日志序列中的位置
• XLogRecord类型代表着该log record的头部信息

REDO函数主要是根据该log record的位置取到对应的log record进行相应的恢复操作，下面我们以堆表INSERT操作为例，分析下对应的REDO函数heap_xlog_insert：

• 调用XLogRecGetData(record)方法，取出上文中的xl_heap_insert结构xlrec
• 如果该XLOG record存在full-page image，则恢复该数据块
• 将上文提到的rdata恢复成tuple，写入到缓存数据块中
• 标记缓存数据块为脏页，等待刷出

通过以上分析，我们可以大体知道XLOG record满足了以下几点才能实现崩溃恢复甚至是任意时间点恢复：

• 可靠性
  1.full-page image，每次checkpoint第一次更新时都需要将整页复制

2.CRC32校验码
3.插入XLOG record时不接受其他信号

• 可重复性
  1.多次重放一个log record，得到的结果相同
• 可恢复性
  1.大多数资源管理器操作对应的log record中存储的都是对应数据在磁盘存储的一个摘要（例如INSERT操作的rdata是tuple的一个摘要）

XLOG日志在PostgreSQL运维中占据了非常重要的地位，从WAL机制到备份恢复以及主备复制，许多功能都离不开XLOG日志。推荐大家看下《PostgreSQL Replication》这本书，加深对PostgreSQL中XLOG以及Replication的理解。

另外，PostgreSQL XLOG目前也存在一些问题，最明显的问题就是写放大，因为full-page image导致XLOG record体积太大，如果设置不合理，可能日志的体积是数据体积的20倍左右。但是经过参数调优，可以尽可能地避免这种情况，可参考文章如何遏制PostgreSQL WAL的疯狂增长。