Re: pg_dump\pg_restore large objects - Mailing list pgsql-ru-general
From | eshkinkot@gmail.com (Сергей Бурладян) |
---|---|
Subject | Re: pg_dump\pg_restore large objects |
Date | |
Msg-id | 87lizlpyom.fsf@home.progtech.ru Whole thread Raw |
In response to | pg_dump\pg_restore large objects (Sergej Kandyla <sk@hlsrv.com>) |
Responses |
Re: pg_dump\pg_restore large objects
|
List | pgsql-ru-general |
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 > 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 > > А на новой базе такой роли нету (или я умышленно хочу сделать для импортируемой > базы другого владельца), > как будет правильно поступать..? Создать нужную роль, а потом её переименовать. Если такая роль уже есть и Вы хотите её изменить - то тут сложнее :) > Я, конечно, понимаю, что при создании базы я указываю и владельца для нее, и > весь импорт будет присвоен указанному владельцу, > но все же. -- С уважением, Сергей Бурладян
pgsql-ru-general by date: