转载：http://book.51cto.com/art/201201/313210.htm

2.5.4 PgArch预写式日志归档进程

Postgresql从8.x版本开始提出了PITR（Point-In-Time-Recovery）技术，支持将数据库恢复到其运行历史中任意一个有记录的时间点。除2.5.3节中所述的WalWriter外，PITR的另一个重要的基础就是对WAL文件的归档功能。PgArch辅助进程的目标就是对WAL日志在磁盘上的存储形式（Xlog文件）进行归档备份。

Postgresql在数据集簇的pg_xlog子目录中始终只使用一个WAL日志文件，这个日志文件记录数据库中数据文件的每个改变。从逻辑上来看，Postgresql数据库会产生一个无限长的顺序的WAL记录序列。Postgresql在物理上把这个WAL记录序列分割成多个WAL文件（每个WAL文件为一个WAL段），通常每个段的大小为16MB（在编译Postgresql时可以通过编译选项改变这个大小）。每个段文件的名字是一个数字，用来反映它们在WAL序列中的位置。即使不进行WAL归档，Postgresql也会创建一些WAL段文件。但是只会使用其中一个来记录WAL日志，如果当前使用的WAL段文件超过了大小限制，则会关闭当前段文件，然后把另外一个可重复使用的段文件作为当前段文件来使用。能够被重复使用的段文件必须保证其中的内容都在最后一次检查点之前产生并保证其中的内容都写入磁盘中。在这种情况下，被保存下来的将只有部分WAL日志，因此也不能实现任意历史时间点的恢复。为实现PITR，需要在WAL段文件被重用时进行归档备份操作，把将被重用的WAL段中的日志记录保存到其他位置。这样归档日志加上当前日志就可以形成连续的WAL日志记录。为了给数据库管理员提供最大的灵活性，Postgresql不对如何归档做任何假设，而是让管理员提供一个shell命令来拷贝一个完整的WAL段文件到备份存储位置。该命令可以就是一个cp命令，或者是一个复杂的shell脚本，所有的操作都由管理员决定。

在postgresql.conf中与预写式日志归档相关的属性有：

archive_mode：表示是否进行归档操作，默认值为off（关闭）。

archive_command：由管理员设置的用于归档WAL日志的命令。

archive_time：表示归档周期，在超过该参数设定的时间时强制切换WAL段，默认值为0（表示禁用该功能）。

为允许归档，需要把postgresql.conf配置文件中的wal_level参数设置为“archive”或“hot_standby”，archive_mode参数设置为“on”，并为archive_command命令指定一个shell命令。在用于归档的命令中，预定义变量“%p”用来指代需要归档的WAL全路径文件名，“%f”表示不带路径的文件名（这里的路径都是相对于当前工作目录的路径）。每个WAL段文件归档时将调用archive_command所指定的命令。当归档命令返回0时，Postgresql就会认为文件被成功归档，然后就会删除或循环使用该WAL段文件。否则，如果返回一个非零值，Postgresql会认为文件没有被成功归档，便会周期性地重试直到成功。

为了标识各个段文件的状态，Postgresql在数据集簇的pg_xlog/archiver_status目录下记录了每一个WAL段文件的状态文件，状态文件的前缀与段文件同名，以表示时间顺序的整数形式命名。状态文件后缀为.ready或者.done，代表段文件的归档状态，分别代表“就绪”和“已完成”两种模式。PgArch进程会找到所有状态为“就绪”的段文件，找到状态文件后，若用户设置了归档命令，PgArch进程将归档命令解析后交由系统的shell函数system(3)执行。文件归档成功后会把pg_xlog/arcive_status目录下相应的状态文件后缀修改为.done。

PgArch进程的启动由函数pgarch_start负责。在该函数中执行fork操作创建Postmaster的子进程PgArch，在新创建的子进程中关闭从Postmaster进程中复制的网络连接端口，同时关闭与父进程的共享内存之间的联系，最后进入PgArch的工作函数PgArchiverMain，其处理流程如图2-11所示。

可见，PgArch进程的执行流程和BgWriter、WalWriter大同小异。PgArch进程在工作循环中检测到需要进行归档时会按照前面介绍的方式找到“就绪”的WAL段文件，然后对其进行归档。完成一次归档之后，PgArch将休眠直至下一次需要归档时。

对WAL日志的归档给管理员提供了一种新的数据库备份策略，这种备份策略组合了文件系统备份与WAL文件的备份。在恢复时，首先恢复数据文件，然后重放WAL日志到指定的时间点。应用这种备份恢复策略，在开始的时候并不需要一个非常完美的一致性备份。任何备份内部的不一致都会被日志的重放动作修改正确。因此，我们不需要文件系统快照的功能，只需要tar或者类似的归档工具。另外，WAL文件的分段归档也把连续的备份简化为了分段的备份。这个功能对大数据库特别有用，因为大数据库的完全备份可能并不方便。如果持续把WAL文件重放给其他装载了同样的基础备份文件的机器，就有了一套“热备份”系统：在任何点我们都可以启动第二台机器，而它拥有近乎当前的数据库拷贝。和简单的文件系统备份技术一样，这个方法只能支持整个数据集簇的恢复。