如何处理用于 Postgres Slave 重置的 WAL 文件

Question

所以昨晚我们的 PG Slave 在大量重新配置磁盘空间、新驱动器等后空间不足，现在报告以下错误：

FATAL:  could not receive data from WAL stream: FATAL:  requested WAL segment 00000001000018F70000008A has already been removed

根据我所做的阅读，似乎唯一的解决方案是使用 pg_start_backup() 等重新同步从站。基于此，我有几个问题。

1. 有没有更好的方法来修复我只是错过或忽略的奴隶？
2. 在备份之前或备份期间，我是否需要清除从属和/或主服务器上的 WAL 文件？
3. 这段时间pg_start_backup 是否锁定了数据库？

根据要求，可以找到日志文件：http : //pastebin.com/9F8vJh6R，已删除文件的其余部分，因为它只有 5 个小时的相同重复错误

非常感谢

Answer 1

如果您在 master 上启用了 WAL 归档（archive_commandis set 和archive_modeis on），请restore_command在副本中设置 arecovery.conf以允许它从 WAL 归档中获取 WAL。

如果没有 WAL 存档，则主副本和副本之间不再有所需增量的记录。所以你必须重新同步它们。

通常这是通过制作新pg_basebackup的副本来完成的。但是，如果副本很大，使用rsync从主节点重新同步副本进行块比较会很有帮助。为此，您：

• pg_start_backup() 在主人身上
• 如果正在运行，请停止副本
• rsync 从主到副本
• pg_stop_backup() 在主人身上
• 将pg_xlog主服务器上的任何其他文件复制到副本，直到报告的文件pg_stop_backup()
• 启动副本

如果您启用了 WAL 归档，则更简单，因为您不必手动复制 WAL，只需restore_command在副本上设置 a 即可。

听起来太复杂了？使用pg_basebackup.

至于你的其他问题：

• 永远不要从 master 中删除 WAL。曾经。非常糟糕。放手pg_xlog。
• pg_start_backup不会“锁定”数据库。它确实防止VACUUM清理死行，因此它会增加高写入活动表的膨胀，但仅此而已。

Answer 2

消息：

requested WAL segment 00000001000018F70000008A has already been removed

意味着主服务器没有保留足够的历史记录来使备用数据库恢复到最新状态。由于您使用的是 9.1 版本，因此您可以使用pg_basebackup创建新的从站。我们使用如下命令：

pg_basebackup -h masterhost -U postgres -D path --progress --verbose -c fast

这不会锁定主人，你也不必rsync或打电话pg_start_backup()给朋友。