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

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

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

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

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

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

Я думал, что смысл использования дампа plain_text заключается в том, что это будет raw, portable SQL. Очевидно, нет.

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

10
export pg-dump postgresql psql restore

5 ответов

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

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

psql -f nvdls.db dbname username
26

использование 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) и только один дамп данных - только дамп схемы, вероятно, потребует какого-либо редактирования.

3

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

эти столбцы будут экспортированы pg_dump с помощью представления " hex " и появятся в вашем файле дампа, например:

выберите pg_catalog.lowrite (0, '\x0a2')

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

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

2

Я решил это, обновив 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
2

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

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

export PGPASSWORD='h0ld1tn0w';

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

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

/ opt / db.вне путь сброса. Вы можете указать свой собственный.

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

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

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

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

0