Используйте pg_restore для восстановления из более новой версии PostgreSQL.

У меня есть (производственный) сервер БД, на котором работает PostgreSQL v9.0, и машина для разработки, на которой работает PostgreSQL v8.4. Я хотел бы сделать дамп производственной БД и использовать его на машине разработки. Я не могу обновить postgres на машине разработчика.

На производственной машине я запускаю:

pg_dump -f nvdls.db -F p -U nvdladmin nvdlstats

На машине разработки я запускаю:

pg_restore -d nvdlstats -U nvdladmin nvdls.db

И я получил эту ошибку:

pg_restore: [archiver] unsupported version (1.12) in file header

Это происходит независимо от того, выбираю ли я формат custom, tar или plain_text при дампе.

Я нашел одно обсуждение в Интернете, в котором предлагается использовать более новую версию pg_restore на машина разработчика. Я попробовал это, просто скопировав двоичный файл 9.0 на машину разработчика, но это не удалось (не неожиданно) из-за проблем с компоновкой.

Я думал, что смысл использования дампа простого_текста в том, что это будет сырой, переносимый SQL. Очевидно нет.

Как я могу получить 9.0 DB в моей установке 8.4?


postgresql psql export restore pg-dump
person Phrogz    schedule 05.01.2011    source источник
comment
У вас может быть параллельная работа как 8.4, так и 9.0 (это то, что я делаю, это работает нормально), таким образом, вы можете оставить 8.4 для локальных проектов, которые зависят от него, но иметь 9.0 для того приложения, которое использует 9: на В долгосрочной перспективе это окупится лучше, чем пытаться восстановить дамп другой версии.   -  person wildpeaks    schedule 29.06.2011
comment
Экспорт и импорт PostgresSQL с помощью pgAdmin III   -  person Somnath Muluk    schedule 26.08.2016

Ответы (5)


arrow_upward
29
arrow_downward

pg_restore только для восстановления дампов, сделанных в "пользовательском" формате.

Если вы делаете дамп «обычный текст», вам нужно использовать psql для запуска сгенерированного сценария SQL:

psql -f nvdls.db dbname username
person a_horse_with_no_name    schedule 05.01.2011

arrow_upward
5
arrow_downward

Использование pg_dump/pg_restore для перехода с 9.0 на 8.4 не поддерживается — поддерживается только переход вперед.

Однако обычно вы можете получить данные (в дампе только данных), а в некоторых случаях вы можете получить схему, но в основном это удача, это зависит от того, какие функции вы используете.

Обычно вы должны использовать целевую версию pg_dump и pg_restore — это означает, что в этом случае вы должны использовать двоичные файлы из версии 8.4. Но вы должны использовать одну и ту же версию pg_dump и pg_restore. Оба инструмента будут нормально работать в сети, поэтому нет необходимости копировать двоичные файлы.

И, как говорит a_horse_with_no_name, вам может быть лучше использовать pg_dump в текстовом режиме — это позволит вам при необходимости отредактировать дамп вручную. В частности, вы можете сделать один дамп только схемы (с ключом -s) и один дамп только данных - только дамп схемы, скорее всего, потребует какого-либо редактирования.

person Magnus Hagander    schedule 05.01.2011
comment
Хорошее предложение по схеме дампа отдельно от данных. У меня было несколько ошибок с использованием простого_текста, но ничего непоправимого. Я не мог попробовать использовать pg_dump с машины разработчика, так как рабочий сервер настроен на запрет удаленных подключений, но это также звучит многообещающе. - person Phrogz; 05.01.2011
comment
Вы можете использовать его удаленно, если у вас есть возможность использовать переадресацию портов SSH (или аналогичную). - person Magnus Hagander; 06.01.2011

arrow_upward
2
arrow_downward

Если база данных версии 9.0 содержит какие-либо столбцы bytea, вас ждут более серьезные проблемы.

Эти столбцы будут экспортированы pg_dump с использованием «шестнадцатеричного» представления и появятся в вашем файле дампа следующим образом:

ВЫБЕРИТЕ pg_catalog.lowrite(0, '\x0a2')

Любая версия бэкенда postgres ниже 9.0 не может найти шестнадцатеричное представление bytea, и я не могу найти возможность сообщить pg_dump на стороне 9.0, чтобы он не использовал его. Установка параметра «bytea_output» по умолчанию на ESCAPE либо для базы данных, либо для всего сервера, по-видимому, игнорируется pg_dump.

Я предполагаю, что было бы возможно пост-обработать файл дампа и фактически изменить каждое значение байта в шестнадцатеричном кодировании на экранированное, но риск неотслеживаемого повреждения вещей, обычно хранящихся в байтах (изображения, PDF-файлы и т. д.), не Удиви меня.

person Matthew    schedule 25.05.2011
comment
По крайней мере, в 9.2.2 настройки bytea_output теперь соблюдаются для pg_dump, поэтому установка для него значения «escape» создаст дамп, совместимый с 8.4, по крайней мере, для полей bytea. Вы по-прежнему получаете некоторые предупреждения о процедурах. - person jishi; 03.04.2013

arrow_upward
2
arrow_downward

Я решил это, обновив postgresql с 8.X до 9.2.4. Если вы используете brew на Mac OS-X, используйте -

brew upgrade postgresql

Как только это будет сделано, просто убедитесь, что ваша новая установка postgres находится вверху вашего пути. Это будет выглядеть примерно так (в зависимости от пути установки версии) -

export PATH=/usr/local/Cellar/postgresql/9.2.4/bin:$PATH
person Blake    schedule 09.08.2013

arrow_upward
0
arrow_downward

У меня была такая же проблема. Я использовал pgdump и psql для экспорта/импорта БД.

1.Установите PGPASSWORD

export PGPASSWORD='h0ld1tn0w';

2. Экспорт БД с помощью pg_dump

pg_dump -h <<host>> -U <<username>> <<dbname>> > /opt/db.out

/opt/db.out — путь к дампу. Вы можете указать свои.

3.Затем снова установите PGPASSWORD другого хоста. Если хост тот же или пароль такой же, то это не требуется.

4.Импортируйте БД на другой хост

psql -h <<host>> -U <<username>> -d <<dbname>> -f /opt/db.out

Если имя пользователя отличается, найдите и замените своим локальным именем пользователя в файле db.out. И убедитесь, что имя пользователя заменено, а не данные.

person Somnath Muluk    schedule 19.10.2016