Re: pg_dump\pg_restore large objects - Mailing list pgsql-ru-general

From Sergej Kandyla
Subject Re: pg_dump\pg_restore large objects
Date
Msg-id 4D9F18EA.8000405@hlsrv.com
Whole thread Raw
In response to Re: pg_dump\pg_restore large objects  (eshkinkot@gmail.com (Сергей Бурладян))
Responses Re: pg_dump\pg_restore large objects  (Dmitriy Igrishin <dmitigr@gmail.com>)
Re: pg_dump\pg_restore large objects  (eshkinkot@gmail.com (Сергей Бурладян))
List pgsql-ru-general
Сергей Бурладян wrote:
> Sergej Kandyla <sk@hlsrv.com> writes:
>
>
>> Слегка запутался с дампами и к своему позору обнаружил,
>> что при обычном дампе (plain text)  large objects не экспортируются!!!
>>
>
> Это не так. LO экспортируются по умолчанию, и в этом легко убедиться
> запустив pg_dump без параметров, например:
> $ pg_dump | grep lo_open
> SELECT pg_catalog.lo_open('16651', 131072);
>
> вообще, это зависит от параметров pg_dump. Например если Вы сохраняете
> только одну таблицу, то LO экспортироваться не будут.
>
> подробнее можно прочитать здесь: http://www.postgresql.org/docs/current/static/app-pgdump.html
>

Спасибо за ответ.


Я, видимо, начитался старых манов из гугла:

http://www.postgresql.org/docs/8.0/static/backup.html
22.1.4. Caveats
For reasons of backward compatibility, pg_dump does not dump large
objects by default. To dump large objects you must use either the custom
or the tar output format, and use the -b option in pg_dump. See the
pg_dump reference page for details. The directory contrib/pg_dumplo of
the PostgreSQL source tree also contains a program that can dump large
objects.

и отсюда сделал такие выводы.

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

Все вылечилось после перехода на бинарный формат. Ни одной ошибки.


>> Бекап, сделанный при помощи custom format:
>> pg_dump -Fc -b -f ${file} ${db}
>> 759M    database.dump
>>
>
> Это сжатый текст. LO в двоичном виде. Чтобы увидеть сколько оно занимает
> без сжатия добавьте параметр -Z0
>
>
>> Бекап, сделанный при помощи tar format:
>> pg_dump -Ft -b -f ${file} ${db}
>> 870M    database.dump.tar
>>
>
> Это несжатый текст, LO в двоичном виде + текстовой файл со схемой данных.
>

Не понял,  момента.
Для переноса базы достаточно  одного из таких дампов.
Из ваших слов выходит   что  -Ft -b  содержит дополнительые схемы
данных, которые отсутствуют в бекапе  "-Fc -b"..


>> И наконец, plain-text бекап:
>> pg_dump -c  -f ${file} ${db}
>> 2.8G   database.sql (plain text)  - откуда???
>> даже если потом сжать этот бекап (tar.gz), то получается 1.1G...
>>
>>
>
> Это несжатый текст, почти такой же как в tar формате, только ещё и LO
> тут в текстовом виде (а это значит что один двоичный байт LO в худшем
> случае в текстовом виде занимает пять байт «\\000»).
>
ясно!

>> 3) Восстановление:
>> даже указывая опцию
>> -c, --clean,   если база уже содержит данные, то импорт заканчивается ошибками.
>>
>> pg_restore -c -d  mydatabase    db.dump
>> ....
>> pg_restore: [archiver] could not create large object 16887
>>
>> Если же базу данных предварительно грохнуть, и потом создать заново, то все ок.
>> Это что, фича такая?
>>
>
> Возможно, Вы предоставили мало информации об ошибке. Вообще, ключ -c
> подразумевает что очищаемая база соответствует той, что в резервной
> копии. Если они различаются — то часть объектов не будет удалена так как
> удаляются только те объекты, которые есть в резервной копии.
>

Указывая эту опцию:     -c, --clean                 clean (drop)
database objects before recreating
я ожидал что будет нечто подобное как в мускиле, и вроде бы оно так и
есть...

DROP TABLE...
CREATE TABLE...

Однако, если база уже была создана и содержала данные,

то ни дамп, сделанный посредством,   pg_dump  --clean
ни  pg_restore -c  ... binary.dump

не отрабатывают корректно (проверял на разных PG серверах.).

Мне такое поведение не ясно.
Для консистентного импорта бекапа, нужно сначала базу грохнуть, потом
создать заново
и тогда уже импортить. В этом случае порядок.

Хотя может такое поведение и вполне оправдано.




>> 4) права доступа.
>> Если в бекапе встречались различные предоставления  привилегий, в духе:
>> ALTER TABLE mydbtable OWNER TO myuser_role
>>
>> А на новой базе  такой роли нету (или я умышленно хочу сделать для импортируемой
>> базы другого владельца),
>> как будет правильно поступать..?
>>
>
> Создать нужную роль, а потом её переименовать. Если такая роль уже есть
> и Вы хотите её изменить - то тут сложнее :)
>
да, все оказалось проще.
аля,
CREATE ROLE newrole
CREATE DATABASE $DBNAME WITH OWNER=newrole

pg_restore -U newrole -O -d  $DBNAME   db.dump



Субьективные выводы:
1.  Не нашел почти никаких преимуществ в plain-text бекапах (кроме как
цели руками его посмотреть)
    binary dump в сумме получается заметно быстрее и портабельнее,
занимает меньше места.
    Перенастроил систему бекапов на этот формат.

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



Спасибо!

pgsql-ru-general by date:

Previous
From: eshkinkot@gmail.com (Сергей Бурладян)
Date:
Subject: Re: pg_dump\pg_restore large objects
Next
From: Dmitriy Igrishin
Date:
Subject: Re: pg_dump\pg_restore large objects