从 Postgres FATAL 中恢复：无法打开文件 pg_tblspc/

Question

我有一个相当大的 PostgreSQL 9.1.3 在 Ubuntu 10.04 上运行。数据分布在多个表空间 = 物理驱动器上。

这些驱动器之一已经消失，因此该表空间的目录不再存在。例如：我丢失了“pg_tblspc/176967555”中的符号链接链接到的目录。

好。状态：重新启动后，该 DBMS 没有出现错误。虽然无法访问该特定数据库

psql: 致命: 无法打开文件 pg_tblspc/176967555/

我试图简单地将这些文件夹创建为空，但是 PG 想要该目录中的一个PG_VERSION和pg_filenode.map文件，我不能简单地创建它。

受影响数据库中 90% 的数据存储在其他正常的表空间中。但是我无法访问数据库中的任何表，因为有些表存储在现已消失的表空间中。

我的目标是从未受影响的表空间读取数据。如果 postgres 只是删除位于该表空间上的任何内容，那就没问题了。

我从丢失的表空间目录中恢复了大部分文件（例如 pg_tblspc/176967555/）。当我将恢复的文件夹放回原位时，PG 在访问该数据库时仍然抱怨丢失的文件 - 一个我无法恢复的文件。

可以使用zero_damaged_pa​​ges =true启动 DBMS帮助忽略丢失的文件吗？如果zero_damaged_pages打算用于 ''missing file'' szenario？编辑：不走运 - 它仍然会抱怨丢失的文件：

set zero_damaged_pages = true;
SET
postgres=# \connect problemdb ;
FATAL:  could not open file "pg_tblspc/176967555/PG_9.1_201105231/123304298/135285149": No such file or directory

我有哪些选择？

我应该继续尝试使用损坏的表空间恢复数据库吗？这个讨论似乎提供了一些关于如何在单个文件丢失时恢复的技巧。我可以用 dd 以某种方式创建这些文件吗？

我应该尝试使用pg_filedump从二进制文件中获取所需的表吗？

有人在 2009 年在 postgres 邮件列表上讨论了将表空间导入新数据库的选项，但似乎没有办法。

这难道不是一个非常正常的崩溃场景：某些文件已经消失——而您仍然不想访问存储在其他文件中的表？

非常感谢您的帮助。史蒂夫

Answer 1

首先要做的就是复制您仍然拥有的所有数据文件，并保证其和所有备份的安全，直到恢复工作完成后很长一段时间。请阅读这个（简短的）Wiki 页面：

http://wiki.postgresql.org/wiki/Corruption

完成此操作后，您可以尝试各种恢复策略，而不必担心在尝试所需的时间之外，您的情况会因尝试而变得更糟。一般来说，我建议仔细遵循文档中描述的技术之一——试图走捷径或发挥创造力往往会导致腐败。只有对 PostgreSQL 内部结构有深入了解的经验丰富的专家才应该尝试偏离记录的步骤。

您没有描述您的备份策略；那里可用的详细信息可能会建议您没有其他选择。

最终，如果您有未备份的有价值的数据，您可能需要手动编辑系统表以消除对丢失表空间的引用。这不适合胆小的人。您可以与许多公司签订此类服务合同，其中许多公司都有从此类灾难性硬件故障中恢复的经验。

http://www.postgresql.org/support/professional_support/

我不隶属于任何这些公司。