主页 / dba / 问题 / 224191
Accepted
Gumuliokas
Asked: 2018-12-06 04:44:06 +0800 CST

postgresql 配置 wal_archive 目录

  • 772

我的 PostgreSQL 服务器有问题。

我从我以前的同事那里接管了 PostgreSQL 服务器，今天我的服务器由于 wal_archives 填满了磁盘空间而崩溃了。

通常 wal 段被放在根目录/wal_archive/中，我检查了它 - 它是空的。前段时间我检查了它，它有一些片段......

我深入挖掘并发现所有 wal 段都存储在pg_data/pg_xlog目录中。

这怎么可能发生？虽然postgresql.conf是这样设置的（仅显示“预写日志”行的启用段）

wal_level = hot_standby                 # minimal, archive, hot_standby, or 
archive_mode = on               # allows archiving to be done
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'

为什么我的 wal_archive 目录现在是空的，而配置设置显示不同的信息？

该wal_archive目录由 root 用户
pg_hba.conf文件拥有，没有任何复制用户 - 我假设服务器上也没有复制。没有像recovery.conf任何地方一样的文件。

cp：无法统计 'pg_xlog/000000010000033C00000081'：没有这样的文件或目录
2018-12-05 14:37:54 EET [7540-1860] 日志：存档命令失败，退出代码为 1
2018-12-05 14:37:54 EET [7540-1861] 详细信息：失败的存档命令是：测试！-f /wal_archive/000000010000033C00000081 && cp pg_xlog/000000010000033C00000081 /wal_archive/000000010000033C00000081
2018-12-05 14:37:54 EET [7540-1862] WARNING: archiving transaction log file "000000010000033C00000081" failed too many times, will tr​​y again later

同样由于恐慌，我不小心删除了 xlog 目录中的大块 wal 段，以启动服务器。现在一切正常，但我想确保将来不会有任何问题。

postgresql replication

1 个回答

  1. Best Answer

    “pg_xlog”是 WAL 文件存储的工作目录，而 PostgreSQL 本身可能仍然需要 WAL 文件，即从断电或其他“软”崩溃中恢复。只有当 PostgreSQL 确定不再需要它们，并且一旦“archive_command”成功完成时，它们才会从那里删除。

    我们无法说出您的“/wal_archive/”发生了什么，但这里有一个似是而非的故事：

    您使用“/wal_archive”作为挂载点挂载了某种网络文件系统（NFS、CIFS 等）。该安装失败并且从未重新建立。这意味着包含您的 WAL 文件的原始文件系统仍然漂浮在某个地方，但计算机不再知道如何访问它。您将以前的 /wal_archive 挂载点视为一个空目录，因为这就是挂载在 Linux 上的工作方式。运行您的 postgres 服务器的用户可能无法写入此残留目录，因为当挂载丢失时，权限也丢失了。因此，archive_command 因权限错误而失败，但您从未注意到这一点，因为您没有查看服务器日志。它反复尝试从 pg_xlog 中归档 WAL 文件，但反复失败。由于它失败了，它永远无法从 pg_xlog 中删除该文件，直到它最终填满。在恐慌中，您从 pg_xlog 中删除了一些文件。现在它仍在尝试归档该文件，但由于不同的原因它现在失败了，该文件不再在 pg_xlog 中，如错误消息“cp: cannot stat 'pg_xlog/000000010000033C00000081'”所示。

    现在你让它再次工作，文件应该出现在 /wal_archive/ 中，或者服务器日志文件中应该有错误告诉你 archive_command 失败。

    请注意，您使用的 archive_command 并不完全安全。它不会在报告成功之前同步刚刚复制到 /wal_archive/ 中的文件内容，因此时间不佳的崩溃可能意味着刚刚归档的文件实际上并不存在于任何地方。您可能想要切换到像“pgbackrest”或“barman”这样的固定解决方案，或者使用流复制来避免这种陷阱。

    另请注意，您认为您拥有的任何备份都可能无效，除非您还进行逻辑备份（如使用 pg_dump）。你最好拿新的并测试它们。

    • 1

相关问题