pg_dump 没有完成

Question

我正在尝试备份我们的 postgres 数据库 (8.4.17)，它的大小约为 25GB。

pg_dump database_name > database_db_dump_2014-05-05.sql

不幸的是，备份在大约 600MB 后停止，并且不会继续。尝试转储特定表 (fb_crawler_event) 时它总是停止。我能够使用--tableswtich成功转储所有其他表。我已经停止了可以与数据库交互的任何其他进程。

---

重启数据库后的服务器日志（对我来说看起来没问题）：

2014-05-05 14:34:46 CEST LOG:  all server processes terminated; reinitializing
2014-05-05 14:34:46 CEST LOG:  database system was interrupted; last known up at 2014-05-05 14:32:50 CEST
2014-05-05 14:34:46 CEST LOG:  database system was not properly shut down; automatic recovery in progress
2014-05-05 14:34:46 CEST LOG:  record with zero length at 1A1/AD6A78C0
2014-05-05 14:34:46 CEST LOG:  redo is not required
2014-05-05 14:34:47 CEST LOG:  database system is ready to accept connections
2014-05-05 14:34:47 CEST LOG:  autovacuum launcher started

---

pg_dump 的详细输出（没有什么可疑的，但是明显的表，它不会让数据库继续转储）

... lots of lines ... pg_dump: restoring data for table "django_site" pg_dump: dumping contents of table django_site pg_dump: restoring data for table "fb_crawler_event" pg_dump: dumping contents of table fb_crawler_event

然后它就停止了。

---

pg_locks 表的输出，对我来说似乎很大（总共 294 个条目）：

  locktype  | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction |  pid  |      mode       | granted 
------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+-----------------+---------
 relation   |    16384 |     2674 |      |       |            |               |         |       |          | 1/23               | 19526 | AccessShareLock | t
 relation   |    16384 |    27367 |      |       |            |               |         |       |          | 1/23               | 19526 | AccessShareLock | t
 relation   |    16384 |   695092 |      |       |            |               |         |       |          | 1/23               | 19526 | AccessShareLock | t
 relation   |    16384 |     2675 |      |       |            |               |         |       |          | 2/7                | 18960 | AccessShareLock | t
 relation   |        0 |     2671 |      |       |            |               |         |       |          | 1/23               | 19526 | AccessShareLock | t
 virtualxid |          |          |      |       | 2/7        |               |         |       |          | 2/7                | 18960 | ExclusiveLock   | t
...

我不是 postgres 专家，所以我想知道数据库是否已损坏？

我怎样才能进一步调试这个异常？

Answer 1

通过将所有文件复制到 /dev/null，我能够找出数据库存储中的哪个文件是罪魁祸首。

cp -vR /usr/lib/postgresql/8.4 /dev/null

（数据库文件的路径可能不同）

无法复制当前文件，但我无法更改它。（所以这很可能是 FS 错误或硬件故障）

所以我用强制 fsck 重新启动了服务器（例如touch /forcefsck），以确保 FS 会尽力修复自身。这可能不是您想要的方式，因为之后可能会丢失全部数据，但我能够事先保留最珍贵的数据，所以我冒了这个风险。

重新启动后，我终于可以再次访问无法访问的表，但我不确定所包含的数据是否已损坏。无论如何，我现在确实有一个备份，我可以对其进行剖析以找出答案，并且我的服务器现在可以重新上线......

我建议阅读有关损坏的 postgres wiki以及此 FOSDEM 演示文稿的幻灯片，以获取有关数据库损坏的更多信息