从 pg_dumpall 恢复 Postgres:关系不存在,命令无效 \N

发布于 2024-10-06 15:17:01 字数 1370 浏览 3 评论 0原文

我在 Linux 服务器上运行 pg_dumpall 我试图在另一台运行相同版本的 postgres (8.1.21-1.el5_5.1) 的 Linux 服务器上恢复生成的文件。

当我尝试恢复时,出现以下错误:

# psql --user=postgres -f pgbackup_dcs.sql postgres
[...]
psql:pgbackup_dcs.sql:10753: ERROR:  relation "sl_event" does not exist
psql:pgbackup_dcs.sql:10754: invalid command \N
psql:pgbackup_dcs.sql:10755: invalid command \N
psql:pgbackup_dcs.sql:10756: invalid command \N
psql:pgbackup_dcs.sql:10757: invalid command \N
psql:pgbackup_dcs.sql:10758: invalid command \N
psql:pgbackup_dcs.sql:10759: invalid command \N
[there are a lot of other errors following this point]

转储文件中的这些行看起来像这样(这里的第一行是 10753)

COPY sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8) FROM stdin;
1       687653  2010-12-08 11:54:45.669861      36713740        36713741                SYNC    \N      \N      \N      \N      \N      \N      \N      \N
1       687654  2010-12-08 11:54:55.6757        36713769        36713770                SYNC    \N      \N      \N      \N      \N      \N      \N      \N
1       687655  2010-12-08 11:55:05.68132       36713796        36713797                SYNC    \N      \N      \N      \N      \N      \N      \N      \N

我在转储或恢复方面做错了什么吗?如何在新服务器上恢复数据库?

I ran pg_dumpall on a Linux server And I'm attempting to restore the resulting file on another linux server, running the same version of postgres (8.1.21-1.el5_5.1).

When I try to restore I get the following errors:

# psql --user=postgres -f pgbackup_dcs.sql postgres
[...]
psql:pgbackup_dcs.sql:10753: ERROR:  relation "sl_event" does not exist
psql:pgbackup_dcs.sql:10754: invalid command \N
psql:pgbackup_dcs.sql:10755: invalid command \N
psql:pgbackup_dcs.sql:10756: invalid command \N
psql:pgbackup_dcs.sql:10757: invalid command \N
psql:pgbackup_dcs.sql:10758: invalid command \N
psql:pgbackup_dcs.sql:10759: invalid command \N
[there are a lot of other errors following this point]

These lines in the dumpfile look like this (first line here is 10753)

COPY sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8) FROM stdin;
1       687653  2010-12-08 11:54:45.669861      36713740        36713741                SYNC    \N      \N      \N      \N      \N      \N      \N      \N
1       687654  2010-12-08 11:54:55.6757        36713769        36713770                SYNC    \N      \N      \N      \N      \N      \N      \N      \N
1       687655  2010-12-08 11:55:05.68132       36713796        36713797                SYNC    \N      \N      \N      \N      \N      \N      \N      \N

Am I doing something wrong with either the dump or the restore? How can I restore the DBs on the new server?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

百变从容 2024-10-13 15:17:01

备份中有 CREATE TABLE sl_event(....) 吗?您尝试将内容复制到不存在的表中,它必须在备份中丢失,或者它是在复制语句之后创建的。

Is there a CREATE TABLE sl_event(....) in the backup? You try to copy content into a table that doesn't exist, it must be missing in the backup or it's created after the copy statement.

情绪操控生活 2024-10-13 15:17:01

使用 pg_dump 一次转储一个数据库。
我认为一次转储一个数据库是个好主意。
我们不需要像 template0、postgres 这样转储系统数据库。

useing pg_dump to dump a single database a time.
I think dump a single a single database a time is good idea.
We useall don't need to dump system db like template0,postgres..

躲猫猫 2024-10-13 15:17:01

经过大量搜索后,我在 postgres 库目录中发现了一些来自 Slony 的额外库文件(xxid.sl 和一些名称中带有“slony”的文件),将这些文件复制到目标服务器后,导入进行得很好。

After a lot of hunting around I found some extra library files in the postgres library directory that were from Slony (xxid.sl and a few files with "slony" in the name), and after copying those to the destination server the import proceeded fine.

梦明 2024-10-13 15:17:01

您是否可以进行仅数据备份?即 pg_dumpall -a 将拒绝创建您的表并会导致类似的结果。除此之外,我的猜测是,如果情况并非如此,那么您有一个上游错误导致了这种情况。

Is it possible you have a data-only backup? I.e. a pg_dumpall -a will decline to create your tables and will result in something like this. Beyond that my guess would be that if that is not the case, then you have an upstream error that is causing this,.

油焖大侠 2024-10-13 15:17:01

我找到了这个修复并且它起作用了

首先删除/删除您想要恢复得太完全的数据库

su - postgres
createdb -T template0 dbname
psql -U username -d dbname -f dumpfile

原因是当 pg_dump 创建一个相对于 template0 的 .dmp 文件时,该文件可能与使用的不同创建数据库
http://openacs.org/forums/message-view?message_id=148479

i found this fix and it worked

First drop/delete the database you want to restore too completely

su - postgres
createdb -T template0 dbname
psql -U username -d dbname -f dumpfile

The reason is that when that pg_dump creates a .dmp files relative to template0 which might be different from the the one used to create the database
http://openacs.org/forums/message-view?message_id=148479

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文