Как восстановить файл дампа PostgreSQL в базы данных Postgres?
У меня есть дамп с файлом .SQL расширение (на самом деле это простой текстовый файл SQL). Я хочу восстановить его в мои созданные базы данных. Я использую pgAdmin III, и когда я использую его "Мастер восстановления", он не выделяет кнопку "Восстановить". Вместо этого он ожидает .backup расширение файла.
Я пытался использовать команды shell для восстановления дампа, но он все равно не работал.
Я новичок в этом. Если бы кто-нибудь мог помочь мне, я был бы обязан.
редактировать
Я использовал следующую команду для панели Shell SQL в PostGres, сидя в newTestDB.
newTestDB-# \i E:\db-rbl-restore-20120511_Dump-20120514.sql
Это все еще выдало ту же ошибку ("Отказано в доступе").
После повышения разрешений он просто показывает мне таблицы по умолчанию PostgreSQL:
List of tablespaces
Name | Owner | Location
-----------+----------+----------
pg_default | postgres |
pg_global | postgres |
(2 rows)
Я не знаю, что делать для импорта / восстановления базы данных из файла SQL.
8 ответов
Вы не упомянули, как была сделана ваша резервная копия, поэтому общий ответ: обычно с psql инструмент.
В зависимости от того, что pg_dump было дано указание сбросить, файл SQL может иметь разные наборы команд SQL. Например, если вы указываете pg_dump выгрузить базу данных используя --clean а также --schema-only вы не можете ожидать, что сможете восстановить базу данных из этого дампа, так как не будет никаких команд SQL для копирования (или вставки, если --inserts используется) фактические данные в таблицах. Подобный дамп будет содержать только команды DDL SQL и сможет воссоздать схему, но не фактические данные.
Типичный дамп SQL восстанавливается с psql:
psql (connection options here) database < yourbackup.sql
или в качестве альтернативы от psql сессия,
psql (connection options here) database
database=# \i /path/to/yourbackup.sql
В случае резервных копий, сделанных с pg_dump -Fc ("пользовательский формат"), который является не простым файлом SQL, а сжатым файлом, необходимо использовать pg_restore инструмент.
Если вы работаете над Unix-подобным, попробуйте это:
man psql
man pg_dump
man pg_restore
в противном случае взгляните на html документы. Удачи!
С помощью команды pg_restore вы можете восстановить базу данных postgres.
Первый открытый тип терминала
sudo su postgres
Создать новую базу данных
создал b [имя базы данных] -O [владелец]
createdb test_db [-O openerp]
pg_restore -d [Имя базы данных] [путь к файлу дампа]
pg_restore -d test_db /home/sagar/Download/sample_dbump
Дождитесь завершения восстановления базы данных.
Помните, что файл дампа должен иметь права на чтение, запись, выполнение, поэтому для этого вы можете применить команду chmod
Проблема с вашей попыткой psql Командная строка - это направление слешей:
newTestDB-# /i E:\db-rbl-restore-20120511_Dump-20120514.sql # incorrect
newTestDB-# \i E:/db-rbl-restore-20120511_Dump-20120514.sql # correct
Чтобы быть понятным, psql Команды начинаются с обратной косой черты, поэтому вы должны были поставить \i вместо. В результате вашей опечатки произошло то, что psql игнорировал все, пока не нашел первый \за которым последовало db, а также \db бывает psql Команда для перечисления табличных пространств, следовательно, почему вывод был список табличных пространств. Это не был список "таблиц по умолчанию PostgreSQL", как вы сказали.
Кроме того, кажется, что psql ожидает filepath аргумент для разграничения каталогов с использованием прямой косой черты независимо от ОС (таким образом, в Windows это было бы нелогично).
Стоит отметить, что ваша попытка "повышения разрешений" не имела никакого отношения к результату команды, которую вы пытались выполнить. Кроме того, вы не сказали, что послужило причиной предполагаемой ошибки "Отказано в доступе".
Наконец, расширение файла дампа не имеет значения, фактически вам даже не нужно расширение. В самом деле, pgAdmin предлагает .backup расширение при выборе имени файла резервной копии, но вы можете сделать его любым, опять же, в том числе без расширения вообще. Проблема в том, что pgAdmin По-видимому, разрешается только "Восстановление" из дампов "Custom or tar" или "Directory" (по крайней мере, так обстоит дело в версии приложения для Mac OS X), поэтому просто используйте psql\i команда, как показано выше.
1. Откройте терминал.
2. Сделайте резервную копию вашей базы данных с помощью следующей команды
Ваш postgres bin - /opt/PostgreSQL/9.1/bin/
ваш исходный сервер базы данных - 192.168.1.111
расположение и имя файла резервной копии - /home/dinesh/db/mydb.backup
ваше имя базы данных источника - mydatabase
/opt/PostgreSQL/9.1/bin/pg_dump --host '192.168.1.111' --port 5432 --username "postgres" --no-пароль - отформатировать пользовательские --blobs --file "/home/dinesh/db/mydb.backup" " моя база данных "
3. восстановить файл mydb.backup в место назначения.
ваш целевой сервер - localhost
имя вашей целевой базы данных - mydatabase
создать базу данных для восстановления резервной копии.
/opt/PostgreSQL/9.1/bin/psql -h 'localhost' -p 5432 -U postgres -c "CREATE DATABASE mydatabase"
восстановить резервную копию.
/opt/PostgreSQL/9.1/bin/pg_restore --host 'localhost' --port 5432 --username "postgres" --dbname "mydatabase" --no-password --clean "/ home / dinesh / db / mydb. резервное копирование"
Сочетая советы от MartinP и user664833, я также смог заставить его работать. Предостережение заключается в том, что при вводе psql из инструмента pgAdmin GUI с помощью выбора плагинов... Консоль PSQL устанавливает учетные данные и уровень разрешений для сеанса psql, поэтому у вас должны быть разрешения Admin или CRUD для таблицы и, возможно, также Admin для БД (не знаю наверняка об этом). Затем команда в консоли psql будет иметь следующий вид:
postgres=# \i driveletter:/folder_path/backupfilename.backup
где postgres=# - приглашение psql, а не часть команды.
Файл.backup будет содержать команды, используемые для создания таблицы, поэтому вы можете также получить в файле такие вещи, как команды "ALTER TABLE ...", которые выполняются, но сообщаются как ошибки. Я полагаю, что вы всегда можете удалить эти команды перед запуском восстановления, но вам, вероятно, лучше, чем сожалеть, сохранить их там, так как они вряд ли приведут к сбою восстановления данных. Но всегда проверяйте, чтобы данные, которые вы хотели восстановить, действительно были там. (Извините, если кому-то это кажется покровительственным советом, но это упущение, которое может случиться с кем бы то ни было, независимо от того, как долго они занимались этим делом - отвлечение внимания от коллеги, телефонный звонок и т. Д., И это легко забыл этот шаг. Я сделал это сам, используя другие базы данных в начале своей карьеры, и подумал: "Ну и дела, почему я не вижу никаких данных из этого запроса?" Ответ был, что данные фактически никогда не восстанавливались, и я просто потратил 2 часа, пытаясь чтобы выследить подозреваемые возможные ошибки, которых не было.)
Это то, что сработало для меня при восстановлении базы данных Postgres в Windows. Для начала щелкните правой кнопкой мыши командную оболочку и выберите «Запуск от имени администратора», чтобы избежать проблем с отказом в разрешении. Выполните ту же команду, но с некоторыми изменениями:
Если вы заметили, команда «newTestDB-# \i E:\db-rbl-restore-20120511_Dump-20120514.sql» была изменена на «newTestDB-# \i E:/db-rbl-restore-20120511_Dump-20120514.sql" с использованием / в пути к файлу вместо косой черты \.
Я считаю, что psql.exe довольно требователен к наклонной плоскости, по крайней мере, на окнах (как показано выше).
Вот пример. В окне cmd:
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres
psql (9.2.4)
Type "help" for help.
postgres=# \i c:\temp\try1.sql
c:: Permission denied
postgres=# \i c:/temp/try1.sql
CREATE TABLE
postgres=#
Вы можете увидеть, что он не работает, когда я использую "нормальные" косые черты Windows \i вызов. Однако оба стиля слеша работают, если вы передаете их в качестве входных параметров psql.exe, например:
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:\TEMP\try1.sql
CREATE TABLE
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:/TEMP/try1.sql
CREATE TABLE
C:\Program Files\PostgreSQL\9.2\bin>
Возможно, вам потребуется установить разрешения на уровне базы данных, что позволит владельцу схемы восстановить дамп.