PostgreSQL WAL 日志发展史 - pg8

一、pg8 实现PITR

WAL的版图终于有所扩张，实现了基于时间点的还原(Point-in-time recovery)简称PITR。PITR是PostgreSQL的物理备份机制，主要流程为：开启归档;制作基础备份;在备份数据库创建recovery.conf文件并写入恢复参数;启动备份数据库。这个博客是讲历史，不讲功能的使用，感兴趣这个博客的读者相信对PITR的使用一定也是了然于胸

PITR的基本原理是，从基础备份的checkpoint点开始，对之后的wal日志进行重演，因此PostgreSQL需要保存基础备份之后所有的wal日志。如图中[GUC3]记录了wal日志归档相关的GUC参数。

ARCHIVE_COMMAND

这个参数为PostgreSQL提供一个wal日志归档的方法执行PITR时，需要为基础备份提供wal日志，可以指定恢复的目标停止位置，相关参数需要写入recovery.conf见[GUC4]

RESTORE_COMMAND

为备份数据库提供获取wal归档的命令

RECOVERY_TARGET_TIME

RECOVERY_TARGET_XID,RECOVERY_TARGET_INCLUSIVE,RECOVERY_TARGET_TIMELINE这是一些恢复目标相关的参数。

二、pg8.2 全页写与温备

在操作系统发生崩溃时，可能会导致PostgreSQL数据页部分写的情况，因此会出现数据不一致的情况。为了应对这一情况，PostgreSQL在一个检查点之后，每次对一个数据页进行修改时，会在wal日志中备份这个数据页（全页写）。

另外本版本有了PostgreSQL温备的概念, 温备是基于wal段级别的wal传递，后面出现的热备是基于walrecord级别的wal传递。温备的备机周期性的通过restore_command获取wal段，并执行wal重演，使得备机在不停的追赶主机的数据。

这里可以理解一下温备和PITR，事实上如果让PITR在wal重演完所有的wal日志后停下来等待后续wal的出现，这就是温备。这个版本‘停下来等待后续wal的出现’这个操作不是在内核中实现的，而是需要你把这一步集成到 restore_command 中。

FULL_PAGE_WRITE

这个参数的意义是使得PostgreSQl可以对抗操作系统崩溃导致导致的部分写问题。

另一方面因为在wal日志中记录了大量的数据页信息，因此会使得wal日志发生膨胀。

另外在做基础备份时执行的checkpoint是不关心FULL_PAGE_WRITE而强制执行全页写的。

ARCHIVE_TIMEOUT

因为wal归档只会对已经写完的wal段生效，因此如果有一个wal段长时间没有写满，那么这个wal段就不会归档，也因此无法在温备功能中被备机使用。

arcihve_timeout定义了一个时间段，如果一个wal段超过这个时间段还没有写满，就强制发生一次wal切换归档。

三、pg8.3 自动刷写wal缓存

8.3版本有一些小的改进和功能增强

SYNCHRONOUS_COMMIT

这个参数定义了，一个事务最终完成的条件。如果参数值为on，那么需要等到事务提交这一条wal日志同步到wal段中，事务才算完成提交。如果参数值为off，那么事务事务提交这一条wal日志刷写到wal缓存即可。在以后的版本中还会对这个参数进行升级使之对应热备的一些同步提交。

WAL_WRITE_DELAY

在说明COMMIT_DELAY 参数时讲到在没有事务提交的情况下，wal缓存只有等到写满才会刷写到磁盘。这里定义了一个时间间隔，在这个时间范围内如果没有刷写wal缓存，那么就触发一次wal缓存刷写。值得注意的是PostgreSQL通过walwrite进程来做这件事情。

ARCHIVE_MODE

这个参数增加是为了将归档模式和archive_command参数分离开。