在初始化内存环境之后, 需要配置Postmaster运行时所需的各种参数. GUC(Grand Unified
Configuration)模块实现了多种数据类型(目前有boolean, int, float,
string四种)的变量配置.这些参数可能由不同的进程在不同的时机进行配置,系统会根据既定的优先权来确定什么情况下的配置可以生效.
共6个:
SysLogger 系统日志进程
BgWriteer 后台写进程
WalWriter 预写式日志写进程
PgArch 预写式归档进程
AutoVacuum系统自动清理进程
PgStat 统计数据收集进程
各个辅助进程的入库文件都是哪些日志信息是数据库管理员获取数据库系统运行状态的有效手段.在数据库出现故障时,日志信息是非常.把数据库日志信息集中输出到一个位置将极大方便管理员维护数据库系统.然而,日志输出将产生大量数据(特别是在比较高的调试级别上),单文件保存时不利于日志文件的操作.因此,
在SysLogger的配置选项中可以调协日志文件的大小,
SysLogger会在日志文件达到指定的大小时关闭当前日志文件,产生新的日志文件.
BgWriter是PG后台将脏页写出到磁盘的辅助进程.
引入该进程主要为达到如下两个目的:
首先,
数据库在进行查询处理时若发现要读取的数据不在缓冲区中时要先从磁盘中读入要读取的数据所在的页面,此时如果缓冲区已满,则需要先选择部分缓冲区中页面替换出去.如果被替换的页面没有被修改过,那么可以直接丢弃;但如果要被替换的页已被修改,则必需先将这页写出到磁盘中后才能替换,这样数据库的查询处理被阻塞.通过使用BgWrite定期写出缓冲区中部分脏页到磁盘中,
为缓冲区腾出空间,就可以降低查询处理被阻塞的可能性.
其次, PG在定期作检查点时需要把所有脏页写出到磁盘,
通过BgWriter预先写出一些脏页,可以减少调协检查点(CheckPoint,
数据库恢复技术的一种)时要进行的IO操作,使系统的IO负载趋向平稳.通过BgWriter对共享缓冲区写操作的统一管理,避免了其他服务进程在需要读入新的页面到共享缓冲区时,不得不将之前修改过的页面写出到磁盘的操作.不过,当BgWriter同时也负责处理所有检查点,它也会定期地发出一个检查点请求,当然也可以由其他进程通过信号要求BgWriter执行一个检查点.
预写式日志WAL(Write Ahead Log,
也称为XLog)的中心思想是对数据库文件的修改必须是只能发生在这些修改已经记录到日志之后,
也就是先写日志后写数据.
如果遵循这个过程,那么就不需要在每次事务提交的时候都把数据块刷回到磁盘,因为在出现崩溃的情况下可以用日志来恢复数据库.
使用WAL主要的好处就是显著地减少了写磁盘的次数,因为在日志提交的时候只需要把日志文件刷新到磁盘,而不是事务修改的所有数据文件.
在多用户环境里,许多事务的提交可以用日志文件的fsync来完成.
而且日志文件是顺序写的, 因此同步日志的开销远比同步数据块的开销要小.
WalWrite的PG8.3以后才新加入的新特性,它避免了其他服务进程在事务提交时需要同步的写入预写式日志到磁盘,
以使得事务提交记录不是在提交时同步写入磁盘,
而是在一个已知的预先设置的时间异步的写入.
同BgWriter一样, 其他服务进程在WalWriter出错时也允许直接进行预写式日志写操作.
PgArch预写式日志归档进程PG从8.x版本开始提出了PITR(Point-In-Time-Recovery)技术,
支持将数据库恢复到其运行历史中任意一个有记录的时间点.
除2.5.3节中所述的WalWriter外,
PITR的另一个重要的基础就是对WAL文件(即XLog)的归档功能.
PgArch辅助进程的目标就是对WAL日志在磁盘上的存储形式(Xlog文件)进行归档备份.
AutoVacuum系统自动清理进程在PG数据库中,对表元组的UPDATE或DELETE操作并未立即删除旧版本的数据,表中的旧元组只是被标记为删除状态,并未立即释放空间.这种处理对于获取多版本并发控制是必要的,如果一个元组的版本仍有可能被其他事务看到,那么就不能删除元组的该版本.
当事务提交后,过期的元组版本对事务不再有效,因而其占据的空间必须回收以供其他元组使用,以避免对磁盘空间增长的无休止的需求,此时对数据库的清理工作通过运行VACUMM来实现.
从PG8.1开始,
PG数据库引入一个额外的可选辅助进程AutoVacuum(系统自动清理进程),自动执行VACUUM和ANALYZE命令,回收被标识为删除状态记录的空间,更新表的统计信息.