pg_standby

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

Synopsis

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

Description

pg_standby 支持创建“热备用”数据库服务器。它被设计为可用于生产的程序，并且如果您需要进行特定的修改，还可以自定义模板。

pg_standby 被设计为正在 await 的restore_command，它是将标准存档恢复转换为热备份操作所必需的。还需要其他配置，所有这些都在主服务器手册中进行了描述(请参阅Section 26.2)。

要将备用服务器配置为使用 pg_standby，请将其放入其recovery.conf配置文件中：

restore_command = 'pg_standby archiveDir %f %p %r'

其中* archiveDir *是应从其中还原 WAL 段文件的目录。

如果指定了* restartwalfile ，通常使用%r宏，则将从 archivelocation 中删除逻辑上在该文件之前的所有 WAL 文件。这样可以最大限度地减少需要保留的文件数量，同时保留崩溃重新启动功能。如果 archivelocation 是此特定备用服务器的临时暂存区域，则使用此参数是适当的，但当 archivelocation *用作长期 WAL 归档区域时，不是。

pg_standby 假定* archivelocation 是服务器所有者用户可读的目录。如果指定 restartwalfile *(或-k)，则archivelocation *目录也必须可写。

当主服务器发生故障时，有两种方法可以故障转移到“热备用”数据库服务器：

• Smart Failover

  • 在智能故障转移中，应用归档文件中所有可用的 WAL 文件后，服务器将启动。即使备用服务器落后，这也将导致零数据丢失，但是如果有许多未应用的 WAL，则备用服务器准备就绪还需要很长时间。要触发智能故障转移，请创建一个包含单词smart的触发文件，或者仅创建该文件并将其留空。

• Fast Failover

  • 在快速故障转移中，服务器将立即启动。归档中尚未应用的所有 WAL 文件将被忽略，并且这些文件中的所有事务都将丢失。要触发快速故障转移，请创建一个触发文件，并将fast写入其中。如果在定义的间隔内没有新的 WAL 文件出现，也可以将 pg_standby 配置为自动执行快速故障转移。

Options

pg_standby 接受以下命令行参数：

• -c

  • 使用cp或copy命令从存档还原 WAL 文件。这是唯一受支持的行为，因此此选项无用。

• -d

  • 在stderr上打印大量调试日志记录输出。

• -k

  • 从* archivelocation 中删除文件，以使当前文件中的 WAL 文件不超过这个数目。零(默认值)表示不从 archivelocation 中删除任何文件。如果指定了 restartwalfile ，则该参数将被忽略，因为该指定方法在确定正确的归档截止点时更为准确。从 PostgreSQL 8.3 开始不推荐使用此参数；指定* restartwalfile *参数更加安全有效。太小的设置可能会导致删除备用服务器重启所需的文件，而太大的设置则会浪费归档空间。

• -r maxretries

  • 设置复制命令失败的最大次数(默认为 3)。每次失败后，我们 await* sleeptime * * * num_retries *，以便 await 时间逐渐增加。因此，默认情况下，我们将 await5 秒钟，10 秒钟，然后 15 秒钟，然后再将故障报告给备用服务器。这将被解释为恢复已结束，因此备用数据库将完全恢复正常。

• -s sleeptime

  • 设置两次测试之间休眠的秒数(最多 60，默认为 5)，以查看要还原的 WAL 文件在归档中是否可用。不一定建议使用默认设置。请咨询Section 26.2进行讨论。

• -t triggerfile

  • 指定一个触发文件，该触发文件的存在应引起故障转移。建议您使用结构化的文件名，以避免在同一系统上存在多个服务器时被触发的服务器混淆。例如/tmp/pgsql.trigger.5432。

• -V
--version

  • 打印 pg_standby 版本并退出。

• -w maxwaittime

  • 设置 await 下一个 WAL 文件的最大秒数，之后将执行快速故障转移。设置为零(默认值)表示永远 await。不一定建议使用默认设置。请咨询Section 26.2进行讨论。

• -?
--help

  • 显示有关 pg_standby 命令行参数的帮助，然后退出。

Notes

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 编写，具有易于修改的源代码，具有专门指定的部分，可根据您的需要进行修改

Examples

在 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的触发文件出现时才停止 await，并根据其内容执行故障转移

• 恢复结束时删除触发器文件

• 从存档目录中删除不再需要的文件

在 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的触发文件出现时才停止 await，并根据其内容执行故障转移

• 恢复结束时删除触发器文件

• 从存档目录中删除不再需要的文件

Windows 上的copy命令设置文件完全复制之前的最终文件大小，这通常会使 pg_standby 感到困惑。因此，一旦 pg_standby 看到合适的文件大小，它将 await* sleeptime *秒。 GNUWin32 的cp仅在文件复制完成后才设置文件大小。

由于 Windows 示例在两端都使用copy，因此其中一个或两个服务器可能正在通过网络访问存档目录。

Author

西蒙·里格斯<[email protected]>

See Also

pg_archivecleanup