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
Re: pg_dump\pg_restore large objects |
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: