pg_standby支持"热备份"数据库服务器的创建。 它设计为一个生产就绪程序,还有一个可定制的模板,定制你需要的特定修改。
pg_standby设计为一个等待的restore_command, 需要将标准归档恢复返回到一个热备份操作。也需要其他配置, 所有这些都在主要服务器手册(参阅第 25.2 节)中描述。
使用pg_standby配置一个备用服务器, 将其放入recovery.conf配置文件中:
restore_command = 'pg_standby archiveDir %f %p %r'
这里的archiveDir是恢复WAL段文件的目录。
如果声明了restartwalfile,通常通过使用%r宏, 然后所有逻辑上在这个文件之前的WAL文件都将从archivelocation 中删除。这最小化了保存崩溃重启能力时需要保留的文件数量。 如果archivelocation对于这个备用服务器来说是瞬态暂存区域, 则使用这个参数是合适的,但在打算将archivelocation 当做长期WAL归档区域时,这是不合适的。
pg_standby假设archivelocation 是拥有服务器的用户可读取的目录。如果声明了 restartwalfile (或 -k), 那么archivelocation目录也必须是可写的。
当主服务器故障时,有两种方法故障切换到"热备用"数据库服务器:
在智能故障切换下,在归档中应用所有WAL文件可用后启用备用服务器。 这样就会零数据丢失,即使备用服务器稍后失败,但是如果有大量未能应用的WAL, 那么在备用服务器准备好之前可能需要大量时间。要触发智能故障切换, 创建一个包含单词smart的触发器文件,或者只是创建它而不写内容。
在快速故障切换下,备用服务器立即启用。归档中任何未应用的WAL文件都将被忽略, 并且所有在这些文件中的事务都丢失。要触发快速故障切换,创建一个触发器文件, 并写入单词fast。如果没有新的WAL文件出现在定义的间隔中, 则pg_standby也可以配置为自动执行快速故障切换。
pg_standby接受下列的命令行参数:
使用cp或copy命令从归档中恢复WAL文件。 这是唯一支持的行为,所以这个选项没什么用处。
在stderr上打印大量调试日志输出。
从archivelocation中删除文件, 这样在归档中保存的当前文件之前不超过这么多WAL文件。 0(缺省)意味着不从archivelocation中删除任何文件。 如果声明了restartwalfile,则忽略这个参数, 因为该声明方法更精确的决定了正确的归档截止点。 这个参数的使用到了PostgreSQL 8.3就废弃了; 声明一个restartwalfile参数更安全也更有效。 太小的设置可能导致删除备用服务器重启仍然需要的文件, 而太大的设置会浪费归档空间。
设置拷贝命令失败时重试的最大次数(缺省是3)。在每次失败之后, 我们等待sleeptime * num_retries, 所以等待时间逐渐增加。因此,默认的,在将失败报告给备用服务器之前, 我们将等待5秒、10秒、然后15秒。这将被解释为结束恢复,并且结果是备用服务器完全启动。
设置测试之间睡眠的秒数(最高60,缺省15),以查看要恢复的WAL文件在归档中是否已经可用。 不一定推荐缺省设置;查阅第 25.2 节获取讨论。
声明一个触发器文件,它的存在会引起故障切换。建议使用结构化的文件名, 以避免多个服务器存在于同一个系统上时,混淆要触发的是哪个服务器; 例如/tmp/pgsql.trigger.5432。
打印pg_standby的版本并退出。
设置执行了快速故障切换之后,等待下一个WAL文件的最大秒数。 设置为0(缺省)意味着永远等待。不一定推荐缺省设置; 查阅第 25.2 节获取讨论。
显示关于pg_standby命令行参数的帮助,然后退出。
pg_standby是设计在PostgreSQL 8.2 及更新版本上使用的。
PostgreSQL 8.3提供了%r宏, 让pg_standby知道它需要保存的最后文件。 在PostgreSQL 8.2中,如果需要清理归档,则必须使用-k 选项。这个选项在8.3中保持可用,但是它的使用已经废弃了。
PostgreSQL 8.4提供了recovery_end_command选项。 没有这个选项,那么剩下的触发器文件可能是危险的。
pg_standby是使用C语言写的, 并且有一个容易修改的源代码,有专门指定的部分用来按你的需要修改。
在Linux或Unix系统上,你可能使用:
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
这里的归档目录在物理上位于备用服务器上,所以archive_command 通过NFS访问它,但是文件对于备用服务器来说是本地的(启用ln)。 这将:
在standby.log中产生调试输出
在检查下一个WAL文件可用性之前睡眠2秒
只在触发器文件调用/tmp/pgsql.trigger.5442出现时停止等待, 并根据它的内容执行故障切换
当恢复结束时删除触发器文件
从归档目录中删除不再需要的文件
在Windows上,你可能使用:
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
请注意,反斜杠在archive_command中需要双写, 但是在restore_command或recovery_end_command 中不需要。这将:
使用copy命令从归档中恢复WAL文件
在standby.log中产生调试输出
在检查下一个WAL文件可用性之前睡眠5秒
只在触发器文件调用C:\pgsql.trigger.5442出现时停止等待, 并根据它的内容执行故障切换
当恢复结束时删除触发器文件
从归档目录中删除不再需要的文件
Windows上的copy命令在文件完全拷贝之前设置最后的文件大小, 这通常会混淆pg_standby。因此pg_standby 一到它认为合适的大小就等待sleeptime秒。 GNUWin32的cp只在文件拷贝完成之后设置文件的大小。
因为Windows示例在两端都使用copy, 所以一个或两个服务器可以通过网络访问归档目录。