pg_dump\pg_restore large objects
От | Sergej Kandyla |
---|---|
Тема | pg_dump\pg_restore large objects |
Дата | |
Msg-id | 4D9483F4.8060901@hlsrv.com обсуждение исходный текст |
Ответы |
Re: pg_dump\pg_restore large objects
|
Список | pgsql-ru-general |
Всем привет. Слегка запутался с дампами и к своему позору обнаружил, что при обычном дампе (plain text) large objects не экспортируются!!! (Хоршо еще, что нюанс всплыл при простой миграции энвайромента...) В связи с этим сопутствующие вопросы. 1) делая бекапы, с указанием custom format, и --blob pg_dump -Fc -b -f ${file} ${db} можно ли быть уверенным что все нужные данные попадают в бекап? Подойдет ли подобный вариант на роль универсального решения, или лучше базы без блобов экспортировать в plain-text ? 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 Бекап, сделанный при помощи tar format: pg_dump -Ft -b -f ${file} ${db} 870M database.dump.tar И наконец, plain-text бекап: pg_dump -c -f ${file} ${db} 2.8G database.sql (plain text) - откуда??? даже если потом сжать этот бекап (tar.gz), то получается 1.1G... 3) Восстановление: даже указывая опцию -c, --clean, если база уже содержит данные, то импорт заканчивается ошибками. pg_restore -c -d mydatabase db.dump .... pg_restore: [archiver] could not create large object 16887 Если же базу данных предварительно грохнуть, и потом создать заново, то все ок. Это что, фича такая? 4) права доступа. Если в бекапе встречались различные предоставления привилегий, в духе: ALTER TABLE mydbtable OWNER TO myuser_role А на новой базе такой роли нету (или я умышленно хочу сделать для импортируемой базы другого владельца), как будет правильно поступать..? Я, конечно, понимаю, что при создании базы я указываю и владельца для нее, и весь импорт будет присвоен указанному владельцу, но все же. Спасибо!
В списке pgsql-ru-general по дате отправления: