From: | eshkinkot(at)gmail(dot)com ( Сергей Бурладя =?utf-8?B?0L0=?=) |
---|---|
To: | Sergej Kandyla <sk(at)hlsrv(dot)com> |
Cc: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: pg_dump\pg_restore large objects |
Date: | 2011-04-07 20:57:13 |
Message-ID: | 87lizlpyom.fsf@home.progtech.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
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
> 1)
> делая бекапы, с указанием custom format, и --blob
> pg_dump -Fc -b -f ${file} ${db}
>
> можно ли быть уверенным что все нужные данные попадают в бекап?
Смотря что Вы имеете ввиду под «нужные», например, можно быть уверенным
что определения пространств таблиц (TABLESPACE) и роли туда точно НЕ попадут.
> 2) Не понимаю, почему такие расхождения по размеру бекапов:
>
> Сама база:
> # du -sh /srv/pgsql/data/base/
> 1.1G /srv/pgsql/data/base/
Это бинарные данные, частично возможно сжатые + индексы.
> Бекап, сделанный при помощи 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 в двоичном виде + текстовой файл со схемой данных.
> И наконец, 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
подразумевает что очищаемая база соответствует той, что в резервной
копии. Если они различаются — то часть объектов не будет удалена так как
удаляются только те объекты, которые есть в резервной копии.
> 4) права доступа.
> Если в бекапе встречались различные предоставления привилегий, в духе:
> ALTER TABLE mydbtable OWNER TO myuser_role
>
> А на новой базе такой роли нету (или я умышленно хочу сделать для импортируемой
> базы другого владельца),
> как будет правильно поступать..?
Создать нужную роль, а потом её переименовать. Если такая роль уже есть
и Вы хотите её изменить - то тут сложнее :)
> Я, конечно, понимаю, что при создании базы я указываю и владельца для нее, и
> весь импорт будет присвоен указанному владельцу,
> но все же.
--
С уважением, Сергей Бурладян
From | Date | Subject | |
---|---|---|---|
Next Message | Sergej Kandyla | 2011-04-08 14:17:14 | Re: pg_dump\pg_restore large objects |
Previous Message | Dmitriy Igrishin | 2011-04-04 16:50:07 | Re: Pg documentation in russian |