0

我有一个 9.0.1 数据库，其中有两个损坏的表（一个表有 20 行，另一个有 140 行）。这些表对于读取/选择操作似乎很好，但更新表中的某些行会产生错误消息：

update media set updated_at = now() at time zone 'UTC';

错误：无法读取文件“base/16384/16485”中的块 2：仅读取 8192 个字节中的 0 个

update media_status set updated_at = now() at time zone 'UTC';

2011-04-14 00:15:15 UTC 错误：无法读取文件“base/16384/16543”中的块 3：只读 8192 个字节中的 0 个
2011-04-14 00:15:15 UTC 声明：更新 media_status 集updated_at = now() 在时区“UTC”；

检查文件系统（linux）中损坏的文件，它们不是零字节：ll base/16384/16485 -rwx------ 1 postgres postgres 16384 2011-04-07 09:43 base/16384/16485

我运行了“vacuum(FULL, VERBOSE)”命令，损坏（或至少更新时的错误）消失了。是否期望“vacuum（FULL）”命令会/可以修复表损坏？这是否为可能发生的事情提供了任何线索？

有没有办法确定这种腐败是如何/何时发生的？

我怀疑它可能发生在文件系统级备份期间（即 pg_start_backup()、tar -czf...、pg_stop_backup()），因为我执行了备份并将数据库移动到不同的系统。恢复文件并启动 postgres 后，我开始收到这些错误。我曾尝试使用相同的 tar 存档多次还原，结果相同（在不同的系统上）。

谢谢，丹

4

1 回答 1

1

很难对这种情况做出明确的陈述，但我会调查存储层。像错误消息这样的短读表明通常在本地、通常附加的存储上“不可能发生”。因此，如果您有 SAN、NAS、NFS、一些重要的 RAID 配置或其他感兴趣的东西，请检查那里的日志或错误计数器。

如果文件在那里，那么这意味着它不是 PostgreSQL 内部的损坏。

尝试一件事会很有趣，但现在可能为时已晚，那就是尝试手动读取文件并查看会发生什么。

VACUUM FULL 修复它的事实可能只是因为它将表完全重写为新文件，所以导致旧文件打嗝的任何东西都消失了。

于 2011-04-14T04:42:22.497 回答