Я использую psql (9.3.9)
в Ubuntu 14.04.
Я создал дамп базы данных с помощью команды:
pg_dump db1 > db1.backup
Я удалил базу данных и воссоздал ее.
Пытаюсь восстановить с помощью psql -d db1 -f /tmp/db1.backup
заканчивается сотнями строк ошибок и ничего не добавляет обратно в базу данных.
Query buffer reset (cleared).
psql:/tmp/db1.backup:19658: invalid command \n
Query buffer reset (cleared).
psql:/tmp/db1.backup:19659: invalid command \n*
Query buffer reset (cleared).
psql:/tmp/db1.backup:19660: invalid command \<text data from my db>
Query buffer reset (cleared).
psql:/tmp/db1.backup:19662: invalid command \n<text data from my db>
Query buffer reset (cleared).
psql:/tmp/db1.backup:19663: invalid command \n<more text data from my db>
Первые выходы выглядят так:
SET
SET
SET
SET
SET
SET
CREATE EXTENSION
COMMENT
SET
SET
SET
Query buffer reset (cleared).
Query buffer reset (cleared).
Query buffer reset (cleared).
...
Другие предлагаемые способы восстановления дампа не работают с теми же ошибками:
postgres=# \i /tmp/db1.backup
Как и этот метод, предложенный в официальной документации:
psql db1 < db1.backup
С помощью pg_restore
тоже не работает:
pg_restore -d db1 /tmp/db1.backup
pg_restore: [archiver] input file appears to be a text format dump. Please use psql.
Как правильно восстановить базу из дампа?
РЕДАКТИРОВАТЬ:
Я обнаружил фактические ошибки после отправки всего вывода в текстовый файл для исследования. Вроде с разрешениями связано.
psql:/tmp/db1:50: ERROR: permission denied to create "pg_catalog.attachments"
DETAIL: System catalog modifications are currently disallowed.
psql:/tmp/db1:53: ERROR: schema "public" does not exist
psql:/tmp/db1:64: ERROR: permission denied to create "pg_catalog.attachments_id_seq"
DETAIL: System catalog modifications are currently disallowed.
psql:/tmp/db1:67: ERROR: schema "public" does not exist
psql:/tmp/db1:73: ERROR: relation "attachments_id_seq" does not exist
psql:/tmp/db1:97: ERROR: permission denied to create "pg_catalog.auth_sources"
DETAIL: System catalog modifications are currently disallowed.
psql:/tmp/db1:100: ERROR: schema "public" does not exist
psql:/tmp/db1:111: ERROR: permission denied to create "pg_catalog.auth_sources_id_seq"
DETAIL: System catalog modifications are currently disallowed.
psql:/tmp/db1:114: ERROR: schema "public" does not exist
psql:/tmp/db1:120: ERROR: relation "auth_sources_id_seq" does not exist
psql:/tmp/db1:137: ERROR: permission denied to create "pg_catalog.boards"
...
EDIT2: с -v ON_ERROR_STOP=1
Мне удалось получить такой результат:
postgres@dbhost:$ psql -d db1 -v ON_ERROR_STOP=1 < db1.backup
SET
SET
SET
SET
SET
SET
CREATE EXTENSION
COMMENT
SET
SET
SET
ERROR: permission denied to create "pg_catalog.attachments"
DETAIL: System catalog modifications are currently disallowed.
Я дал права postgres-user на целевую базу данных с помощью команд:
grant all privileges on database db1 to postgres;
EDIT3: это точная команда, которую я использовал для создания дампа:
root@dbhost:~# su -c "pg_dump db1 > db1.backup" postgres
РЕДАКТИРОВАТЬ4:
postgres@dbhost:/ head -50 db1.backup
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;
--
-- Name: plpgsql; Type: EXTENSION; Schema: -; Owner:
--
CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
--
-- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner:
--
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
SET search_path = public, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: attachments; Type: TABLE; Schema: public; Owner: mydbuser; Tablespace:
--
CREATE TABLE attachments (
id integer NOT NULL,
container_id integer,
container_type character varying(30) DEFAULT NULL::character varying,
filename character varying(255) DEFAULT ''::character varying NOT NULL,
disk_filename character varying(255) DEFAULT ''::character varying NOT NULL,
filesize integer DEFAULT 0 NOT NULL,
content_type character varying(255) DEFAULT ''::character varying,
digest character varying(40) DEFAULT ''::character varying NOT NULL,
downloads integer DEFAULT 0 NOT NULL,
author_id integer DEFAULT 0 NOT NULL,
created_on timestamp without time zone,
description character varying(255),
disk_directory character varying(255)
);
id integer NOT NULL,
-
postgres@dbhost:/$ grep search_path db1.backup
SET search_path = public, pg_catalog;
Это также соответствует сотням строк данных в моей базе данных, мне пришлось их пропустить. Возможно, я также пропустил некоторые команды:
postgres@dbhost:/$ grep attachments db1.backup
-- Name: attachments; Type: TABLE; Schema: public; Owner: dbuser; Tablespace:
CREATE TABLE attachments (
ALTER TABLE public.attachments OWNER TO dbuser;
-- Name: attachments_id_seq; Type: SEQUENCE; Schema: public; Owner: dbuser
CREATE SEQUENCE attachments_id_seq
ALTER TABLE public.attachments_id_seq OWNER TO dbuser;
-- Name: attachments_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: dbuser
ALTER SEQUENCE attachments_id_seq OWNED BY attachments.id;
ALTER TABLE ONLY attachments ALTER COLUMN id SET DEFAULT nextval('attachments_id_seq'::regclass);
-- Data for Name: attachments; Type: TABLE DATA; Schema: public; Owner: dbuser
COPY attachments (id, container_id, container_type, filename, disk_filename, filesize, content_type, digest, downloads, author_id, created_on, description, disk_directory) FROM stdin;
-- Name: attachments_id_seq; Type: SEQUENCE SET; Schema: public; Owner: dbuser
-
root@dbhost:~# grep -i 'create schema' db1.backup
<no results>
Просто добавляю свой опыт:
Мне нужно было заранее создать схемы, которые восстанавливались. Если схемы не существовали до восстановления, восстановление таким образом не удалось. В остальном никаких проблем.
Как ни странно, у меня была эта проблема только в одной из моих баз данных, которые (AFAIK) были настроены одинаково, все с настройками по умолчанию. Так было с несколькими резервными копиями. Впервые это произошло сегодня, после нескольких месяцев работы, когда я отбрасывал схему и оставлял ее несуществующей, прежде чем восстанавливать ее из дампа. Страшно ...
Похоже, в исходном дампе есть что-то действительно странное. Должно быть что-то вроде CREATE TABLE pg_catalog.attachments
заявление на свалку. Это не должно быть возможным, поскольку вы не можете создавать таблицы в pg_catalog
если только опция отладки allow_system_table_mods
является on
.
Единственный другой способ, которым я могу представить это, - это если каким-то образом search_path
это создается pg_dump
скрипт каким-то образом недействителен. Например, если CREATE SCHEMA myschema
не запускается, search_path
возможно myschema,pg_catalog
, который, если myschema
отсутствует, приведет к pg_catalog
быть целью CREATE TABLE
.
Это не должно быть возможным с нормальным pg_dump
запустить.
Проверьте search_path в дампе (резервной копии), который вы используете для восстановления. Когда вы делаете резервную копию с использованием пользователя, например: postgresql в резервной копии, search_path будет примерно таким, как set search_path = postgres, pg_catalog, sys, dbo, и во время восстановления, если он не может найти схему postgresql, он попытается восстановить в pg_catalog схема, которая потерпит неудачу.
Когда вы пытаетесь сделать резервную копию всей базы данных, стоит использовать pg_dumpall, что касается конкретной резервной копии базы данных - у меня нет никаких проблем, когда я делаю это следующим образом:
pg_dump -o -h <host> -U roleName -d dbName -n "\"SCHEMA\"" > schema_name.dump
vi schema_name.dump
затем :%s/roleName/newRoleName/g
ИЛИ для любого размера sed -i -- 's/roleName/newRoleName/g' schema_name.dump
psql -U newRoleName newDbName -h <host> < schema_name.dump