Re: pg_dump\pg_restore large objects

Сергей Бурладян 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 -С я знаю,  но считаю не очень портабельным, поэтому не использую).

Спасибо!

--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general