rulinux.net - Форум - Talks - Перипетии восстановления схемы из pg_dump http://rulinux.net/ rulinux.net - Форум - Talks - Перипетии восстановления схемы из pg_dump http://rulinux.net/ http://rulinux.net/rss_icon.png Re:Перипетии восстановления схемы из pg_dump https://rulinux.net/message.php?newsid=43201&page=1#223142 https://rulinux.net/message.php?newsid=43201&page=1#223142 Sun, 04 Nov 2018 20:34:31 +0300 > pg_dump делает один sql-файл, либо один файл в их бинарном формате, чего, обычно, достаточно. Как ты получил такое?

Опцией "-Fd", наверное. И вроде бы без "--schema-only"... Точно не скажу - скрипт сгинул вместе с хостом.

> Точнее, зачем так?

Показалось, что это хорошая идея - скрипт отдельно, данные отдельно. Скрипт хотя бы обозримый получается.

> С COPY всё ок, читаешь-то не ты, а демон БД, который работает под юзером postgres.

Да? А в конструкции "COPY config (id, name, value) FROM stdin;" - демон БД будет из своего stdin читать? Не логично. Кстати, нафига они эту команду туда понавставили?

]]> Re:Перипетии восстановления схемы из pg_dump https://rulinux.net/message.php?newsid=43201&page=1#223141 https://rulinux.net/message.php?newsid=43201&page=1#223141 Sun, 04 Nov 2018 12:51:20 +0300 >файл restore.sql и несколько файлов цифра.dat
Откуда такие сложности?

pg_dump делает один sql-файл, либо один файл в их бинарном формате, чего, обычно, достаточно. Как ты получил такое? Точнее, зачем так?

С COPY всё ок, читаешь-то не ты, а демон БД, который работает под юзером postgres.

]]> Перипетии восстановления схемы из pg_dump https://rulinux.net/message.php?newsid=43201&page=1#223140 https://rulinux.net/message.php?newsid=43201&page=1#223140 Sun, 04 Nov 2018 08:33:02 +0300 Попробовал тут восстановить схему, сделанную pg_dump.

Дамп выглядит так: есть файл restore.sql и несколько файлов цифра.dat - по одному на каждую таблицу, видимо.

Запустил из-под админа psql с restore.sql - не работает. Почитал что внутри - пишут мол, пути к файлам данных, лежащих тут же, рядом со скриптом восстановления мы указали как $$PATH$$ - замените сами как-нибудь на правильные перед восстановлением. Т.е. файлы в скрипте поминаются как '$$PATH$$/3009.dat'. Ну, ОК, думаю, ща поменяю.. В результате такое заклинание пришлось мучительно изобретать:
bash

sed -i "s+\\\$\\\$PATH\\\$\\\$+$PWD+g" restore.sql
 

Блин педорасы, ну зачем доллары туда было совать? Мало других символов чтобы переменную выделить если она вообще нужна??

Идём дальше. Просто офигеть - зачем-то его дамп при восстановлении сносит схему public. Закомментировал. Запускаю снова - ругается что нет юзеров, которым должны быть даны права на объекты. Почему-то юзеры вот не забэкапились. Да ещё я овнеру другое имя дал. Фак. Переименовываю овнера в дампе, слава богу он не пересекается с именами объектов. Создаю отсутствующих юзеров. Запускаю снова - данные всё равно не восстанавливаются!

Смотрю как оно эти данные должны читаться:
bash

COPY config (id, name, value) FROM stdin;
\.
COPY config (id, name, value) FROM '$$PATH$$/3009.dat';
 
Для начала не понимаю смысла вставлять загрузку из пустого STDIN. Ну хрен с ним, вроде ничего страшного делать не должно. Но что же с файлами? В измененном скрипте $$PATH$$ уже поменян на реальный полный путь к файлу, файл есть, я его владелец. Хм, _Я_ его владелец. Меняю владельца на постгрес - всё заработало. Ну вот какого хрена не прочитать файл с моими правами?

Вобщем мракобесие какое-то, а не backup/restore. Как люди с этим живут??

]]>