PostgreSQL full_page_writes 机制分析

对于 PG 的 full page write 和 MySQL 的 double write 机制一直有些困惑,如果没有这些机制,是不是在页断裂的情况下数据一定就有问题?如果应用 redo log 或者 wal 是幂等设计的,在刷脏页的过程中,无论怎么 crash,只要支持幂等,是否就无需担心页断裂的问题。

带着上述问题,结合 PG 的实现,大致有了答案,以下分析如果有不对的,欢迎指出。

为什么 PG 没有设置 full_page_writes,就可能会导致崩溃后无法恢复?

首先这里说的崩溃是指在刷脏页过程中产生的崩溃,并且导致了页断裂。什么是页断裂?简单来说就是 PG 的数据页只有部分被写入到了磁盘,页面的 crc32 检验值不正常。比如 PG 一个页面通常 8KB,而操作系统一次原子写入的页面可能为 4KB 或者更小的 512 B,这样就可能导致 1 个 8KB 的页面只有一部分写入成功,这种现象称之为页断裂。

产生页断裂后,为什么会影响后面的恢复过程?

PG 崩溃恢复时,以 checkpoint 检查点为起始点,在原始页面的基础上,应用 wal 日志。原始页面发生损坏,也就无法正常应用 wal 日志。因为应用 wal 日志时,会读取原始页面的数据,比如原始页面的的下一条记录的偏移值,原始页面发生损坏,读出来的数据已经不再可靠,基于损坏的原始页面恢复出来的数据,也不再可靠,即使强行做崩溃恢复,也可能会产生数据不一致。

看看官方文档的解释:

官方文档说【存储在 wal 中的行级变化数据不足以恢复这样一个页面】,如何理解这句话?来看一个 insert 产生的 wal 日志记录,里面包含两个重要信息。

第一个是这条 wal 记录属于哪个表空间文件以及哪个 page,对应的结构如下:

typedef struct RelFileNode
{
	Oid			spcNode;		/* tablespace */
	Oid			dbNode;			/* database */
	Oid			relNode;		/* relation */
} RelFileNode;

typedef uint32 BlockNumber;

RelFileNode 表示表空间 Oid 、数据库 Oid 以及表 Oid。BlockNumber 表示该条记录所属的页面号。

第二个是这个记录的 insert 相关的记录头信息,如下:

/* 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_insert;

offnum 表示该条记录在页面内的序号,即这个页面上的第几条记录,官方文档中说的行级变化数据就是指这个数据。通过这个数据不能找到该记录对应在页面内的物理位置,物理位置需要读取页面的其他内容。在页面损坏的情况下,从页面读取的任何其他数据都不再可靠,所以无法依赖不可靠的数据来应用 wal 日志。

举个例子:

对于一个损坏的页面,其下一条记录指向的位置为 8000,因为该页面已经损坏,crc32 校验不对,此时应用一条 insert wal 记录,不管其 offnum 是多少,需要从页面中读出下一条插入记录对应的页面物理位置,读出来的 8000 到底是不是有效的,无法确认。

full_page_writes 如何避免页断裂问题?

有了 full_page_writes 机制,每次 checkpoint 之后页面的首次更新,都会将页面完整的写入到 wal 日志中。如果在刷脏页时发生崩溃,并且在恢复时发现原始页面损坏,就可以通过 wal 里面的 full page 进行恢复。

然而 full_page_writes 也带来了不小的性能开销。

文章评论

0条评论