anonymous@RULINUX.NET~# Last login: 2024-12-27 14:27:47
Регистрация Вход Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск
[#] [Добавить метку] [Редактировать] Фильтры
  • торсионщина
Скрыть

Перипетии восстановления схемы из pg_dump

Попробовал тут восстановить схему, сделанную 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. Как люди с этим живут??

anonymous(*) (2018-11-04 12:33:02)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

[Ответить на это сообщение]
[#] [Добавить метку] [Редактировать] Ответ на: Перипетии восстановления схемы из pg_dump от anonymous 2018-11-04 12:33:02
avatar
Скрыть

Re:Перипетии восстановления схемы из pg_dump

>файл restore.sql и несколько файлов цифра.dat
Откуда такие сложности?

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

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

SystemV(*)(2018-11-04 16:51:20)

Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
[#] [Добавить метку] [Редактировать] Ответ на: Re:Перипетии восстановления схемы из pg_dump от SystemV 2018-11-04 16:51:20
avatar
Скрыть

Re:Перипетии восстановления схемы из pg_dump

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

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

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

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

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

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

anonymous(*)(2018-11-05 00:34:31)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Этот тред читают 1 пользователь:
Анонимных: 1
Зарегистрированных: 0




(c) 2010-2020 LOR-NG Developers Group
Powered by TimeMachine

Valid HTML 4.01 Transitional Правильный CSS!