Здравствуйте, товарищи. Долгое время администрировал сервер PostgreSQL 9.4.5 и не знал проблем (уровень знаний минимальный). Тут появилась необходимость восстановить базу в которой хранятся почтовые вложения (картинки, пдф и прочее файлы, которые занимают место). Сама база весит 70 гиг, ее бекап (образ) 40 гиг.
Стандартной командой делаю восстановление базы в чистую БД
psql DOC_copy < / BACKUP/SQL/DOC.2017.06.11.bak
Команда преждевременно заканчивает работу (на мой взгляд), так как новая база весит всего 20 гиг (вместо ~70) и естественно она не рабочая.
Почему то образ "не полностью восстанавливается", а частично... Т.е. доходит до какого то места и останавливается. Хотя в логах я никаких ошибок не вижу. И Postgre никак не ругается - просто останавливает восстановление.
Подскажите, как выяснить причину? Требуется настроить логирование сервера определенный образом? Спасибо за любую помощь.
Насчёт рабочая база или нет -
Насчёт рабочая база или нет - спорить не буду.
Но если нет ошибок, то попробуйте с той базы, что восстановилась снова сделать бакап. Если его размер будет приблизительно таким как у первоначального бакапа, значит такой бакап у вас.
Еще сегодня провел
Еще сегодня провел эксперимент. Если восстанавливать БД из образа, то при корректном завершении процедуры в консоль выводятся такие команды REVOKE и GRANT. А вот с этой проблемной базой, таких волшебных слов нет. Восстановление заканчивается на "COPY 48357" Возможно, в этом какая то проблема? Число 48357 большое...
Попробуйте вызвать psql для
Попробуйте вызвать psql для восстановления бакапа, установив переменную окружения VERBOSITY в значение "verbose" или "terse"
Может какую доп. инфу выдаст.
Мне повезло!
Спасибо Вам за помощь и знания. Вероятнее всего из-за проблем БД оригинала - образ создавался дефектный. В оригинальный БД была ошибка типа
"ERROR: invalid page in block xxxxxx of relation base/zzzzzz/yyyyyy"
В логах посмотрел к какой таблице это относится (к таблице которая весит более 40 гиг, в которой хранятся файлы)
Я стал пробовать починить БД оригинал.
Помогли команды:
SET zero_damaged_pages = on;
REINDEX TABLE public._xxxxxxx;
После чего при создании дампа появилась другая ошибка.
unexpected chunk number 3412 (expected 3408) for toast value 261422400 in pg_toast_152925113
Почитав на форумах - пишут, что надо удалить все строки ссылающиеся на этот объект (я хз как это сделать).
Но мне повезло, что эта БД используется 1С. Я в 1С удалил всякую "парашу" (куча левых файлов, которые никому не нужны) и в числе этой "параши" оказалась проблемная строка. Все работает без ошибок (дамп и восстановление, все ок). Теперь опасаюсь хранить файлы в Постгрес....
А не надо файлы хранить в
А не надо файлы хранить в PostgreSQL.
Я где-то уже писал по этому поводу. Не нужно хранить файлы в СУБД, которая для этого не предназначена и я не про PostgreSQL, а вообще про любую СУБД. Ведь в чём смысл СУБД? Наличие в БД информации, по которой осуществляется поиск, которую можно индексировать, агрегировать и т.д. А в случае хранения файлов, вы превращаете СУБД в хранилище "мёртвой" информации, которую нельзя индексировать, по которой не выполнить поиск и т.д. При этом файлы быстро увеливают размер БД до безобразия, требуя от СУБД огромных ресурсов и томозя её работу. Тогда зачем? В СУБД может хранится КАТАЛОГ файлов, с описанием файлов и путями, а сами файлы должны хранится на файловом сервере.
Вы правы!
Спасибо за помощь!