From: | Sergej Kandyla <sk(at)hlsrv(dot)com> |
---|---|
To: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: pg_dump\pg_restore large objects |
Date: | 2011-04-08 14:17:14 |
Message-ID: | 4D9F18EA.8000405@hlsrv.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
Сергей Бурладян wrote:
> Sergej Kandyla <sk(at)hlsrv(dot)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 -С я знаю, но считаю не очень портабельным, поэтому
не использую).
Спасибо!
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2011-04-08 19:17:12 | Re: pg_dump\pg_restore large objects |
Previous Message | Сергей Бурладя =?utf-8?B?0L0=?= | 2011-04-07 20:57:13 | Re: pg_dump\pg_restore large objects |