无法从损坏的 PostgreSQL 表中恢复数据

Question

我正在尝试在最近的数据库损坏后恢复我的数据库。现在我有两张桌子真的给我带来了麻烦。

当我做select count(*)一张桌子返回：

错误：无法访问事务 2619431010 的状态
详细信息：无法打开文件“pg_clog/09C2”：没有这样的文件或目录。

另一个返回：

错误：关系基/11974232/11975439 的块 94206 中的页头无效

有什么方法可以解决并取回我的数据？

Answer 1

当您遇到数据库损坏时，您应该做的第一件事是在 PostgreSQL 未运行时捕获数据目录树的文件系统副本并将其保存在安全的地方。

完成后，如果您没有可以恢复的备份，您可能想尝试pg_resetxlog。请注意，文档中有此建议：

您应该立即转储数据，运行 initdb，然后重新加载。重新加载后，检查不一致并根据需要进行修复。

通读文档页面，pg_resetxlog直到您了解选项以及哪些可能最适合您的情况。

最后，确保您了解数据库是如何损坏的。

• 通常这是由于硬件或驱动程序错误造成的。

• 有时是由于使用了非默认的 PostgreSQL 设置，这允许 DBA 降低可靠性以提高性能。一些拥有冗余服务器的商店发现这是一个值得的权衡，因为在大型冗余服务器群中丢失一台服务器没什么大不了的。你可能会听到这种类型的配置被称为“拿着剪刀奔跑数据库管理员”，并主要包括关闭fsync，full_page_writes以及synchronous_commit-需要所有这些都保证提交的事务的持久性。前两个是防止操作系统或硬件崩溃时数据库损坏所必需的。您不应该关闭这些，除非可以丢失整个 PostgreSQL 实例。

• 很少有人会删除数据库的某些组成部分，例如pg_xlog或pg_clog子目录。

• 更罕见的是，有一个 PostgreSQL 错误导致了损坏。因为任何关于此类错误的报告都会得到非常认真的对待，所以它们往往会很快得到修复，并且如今人们通常会遇到运行已不再受支持的过时版本的人。在不知道确切版本（来自 的输出SELECT version();）的情况下，很难知道您是否容易受到已知的、已修复的错误的影响。可能与此特定错误消息相关的是您是否使用了 pg_upgrade 以及您使用的确切版本。