9.3 9.4 9.5 9.6 10 11 12 13
阿里云PostgreSQL 问题报告 纠错本页面

pg_standby

名称

pg_standby -- 支持PostgreSQL热备份服务器的创建

大纲

pg_standby [option...] archivelocation nextwalfile xlogfilepath [restartwalfile]

描述

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接受下列的命令行参数:

-c

使用cpcopy命令从归档中恢复WAL文件。 这是唯一支持的行为,所以这个选项没什么用处。

-d

stderr上打印大量调试日志输出。

-k

archivelocation中删除文件, 这样在归档中保存的当前文件之前不超过这么多WAL文件。 0(缺省)意味着不从archivelocation中删除任何文件。 如果声明了restartwalfile,则忽略这个参数, 因为该声明方法更精确的决定了正确的归档截止点。 这个参数的使用到了PostgreSQL 8.3就废弃了; 声明一个restartwalfile参数更安全也更有效。 太小的设置可能导致删除备用服务器重启仍然需要的文件, 而太大的设置会浪费归档空间。

-r maxretries

设置拷贝命令失败时重试的最大次数(缺省是3)。在每次失败之后, 我们等待sleeptime * num_retries, 所以等待时间逐渐增加。因此,默认的,在将失败报告给备用服务器之前, 我们将等待5秒、10秒、然后15秒。这将被解释为结束恢复,并且结果是备用服务器完全启动。

-s sleeptime

设置测试之间睡眠的秒数(最高60,缺省15),以查看要恢复的WAL文件在归档中是否已经可用。 不一定推荐缺省设置;查阅第 25.2 节获取讨论。

-t triggerfile

声明一个触发器文件,它的存在会引起故障切换。建议使用结构化的文件名, 以避免多个服务器存在于同一个系统上时,混淆要触发的是哪个服务器; 例如/tmp/pgsql.trigger.5432

-V
--version

打印pg_standby的版本并退出。

-w maxwaittime

设置执行了快速故障切换之后,等待下一个WAL文件的最大秒数。 设置为0(缺省)意味着永远等待。不一定推荐缺省设置; 查阅第 25.2 节获取讨论。

-?
--help

显示关于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)。 这将:

在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_commandrecovery_end_command需要。这将:

Windows上的copy命令在文件完全拷贝之前设置最后的文件大小, 这通常会混淆pg_standby。因此pg_standby 一到它认为合适的大小就等待sleeptime秒。 GNUWin32的cp只在文件拷贝完成之后设置文件的大小。

因为Windows示例在两端都使用copy, 所以一个或两个服务器可以通过网络访问归档目录。

作者

Simon Riggs

又见

pg_archivecleanup
<
/BODY >