powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Восстановление БД... те же грабли по новым местам...
4 сообщений из 4, страница 1 из 1
Восстановление БД... те же грабли по новым местам...
    #39696482
bid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bid
Гость
Доброго времени суток, уважаемые!
Проблема стара как мир, но поиск не по форуму не по инету прямого результата не дал, либо глаза уже не видят.
Ос Windows Srv2008
Posgres 9.4 + PgAdmin3
Упали базы 1с, бэкапов нужных баз нет. В постгресе как балерина с гранатометом.
Персонаж на горячую скопировал базы (папку data) на другой диск, без остановки службы - все упало(служба отключилась и перестала запускаться) -раз.
Вернули назад - служба не запустилась, переустановили постгрес - служба заработала, прописали вручную новые базы, подсунули старые базы (старую папку data) - не заработало два.

Логи сыпали ошибку:
2018-08-31 12:08:07 BDT СООБЩЕНИЕ: неверная запись первичной контрольной точки
2018-08-31 12:08:07 BDT СООБЩЕНИЕ: неверная запись вторичной контрольной точки
2018-08-31 12:08:07 BDT ПАНИКА: не удалось считать правильную запись контрольной точки
2018-08-31 12:08:07 BDT СООБЩЕНИЕ: стартовый процесс (PID 5444) завершился с кодом выхода 3
2018-08-31 12:08:07 BDT СООБЩЕНИЕ: прерывание запуска из-за ошибки в стартовом процессе


С помощью pg_controldata и pg_resetxlog, сбросили контрольные точки и запустили службу, вернули список баз в PgAdmin, среди которых оказались и целевые бд, НО!

При подключении к базе, на экран выходит очень большая ошибка, постараюсь скрыть ее в спойлер, достали из логов:
2018-08-31 16:26:03 BDT ОШИБКА: expected "]" to end datum, but got "0 0 0 0 ]} :resulttype 26 :resulttypmod -1 :resultcollid 0 :relabelformat 2 :location -1}) :location 1030}) :location 1014} :alias <> :rtindex 5}) :quals {VAR :varno 5 :varattno 7 :vartype 16 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 5 :varoattno 7 :location 1045}} :targetList
//Сокращено для экономии места//
{TARGETENTRY :expr {VAR :varno 5 :varattno 14 :vartype 1009 :vartypmod -1 :varcollid 100 :varlevelsup 0 :varnoold 5 :varoattno 14 :location 909} :resno 9 :resname useconfig :ressortgroupref 0 :resorigtbl 2964 :resorigcol 3 :resjunk false}) :withCheckOptions <> :returningList <> :groupClause <> :havingQual <> :windowClause <> :distinctClause <> :sortClause <> :limitOffset <> :limitCount <> :rowMarks <> :setOperations <> :constraintDeps <>})"; length = 4 (символ 40)

2018-08-31 16:26:03 BDT ОПЕРАТОР: SELECT usecreatedb, usesuper, CASE WHEN usesuper THEN pg_postmaster_start_time() ELSE NULL END as upsince, CASE WHEN usesuper THEN pg_conf_load_time() ELSE NULL END as confloadedsince, CASE WHEN usesuper THEN pg_is_in_recovery() ELSE NULL END as inrecovery, CASE WHEN usesuper THEN pg_last_xlog_receive_location() ELSE NULL END as receiveloc, CASE WHEN usesuper THEN pg_last_xlog_replay_location() ELSE NULL END as replayloc, CASE WHEN usesuper THEN pg_last_xact_replay_timestamp() ELSE NULL END as replay_timestamp, CASE WHEN usesuper AND pg_is_in_recovery() THEN pg_is_xlog_replay_paused() ELSE NULL END as isreplaypaused
FROM pg_user WHERE usename=current_user
По второй части запросов кидает окна ошибки не найденных колонок...

После подключения и отщелкивания всех ошибок, целевые бд становяться активными в PgAdmin'e но подцепить их к 1с не удается... pg_dump не проходит, возвращает ошибку 1
Подскажите есть ли шансы вернуть БД в рабочий вид? Если да то какими действиями?
Если необходима дополнительная информация напишите, желательно сразу где посмотреть...
Заранее благодарю всех кто откликнется с дельным советом!
...
Рейтинг: 0 / 0
Восстановление БД... те же грабли по новым местам...
    #39696493
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bid,

нет. Шансов нет. После pg_resetxlog консистентное состояние базы восстановить практически нереально. Это специальная утилита целью которой является именно сломать всё.
Если знаете что куда и как в базе пишет это 1с - попытайтесь достать с консольного psql copy запросами отдельные таблички и анализируйте, что из этого правдоподобно, а что нарушает логику данных.

Какие копии PGDATA есть? Или вы были достаточно смелы, чтобы так и не сделать копию?
...
Рейтинг: 0 / 0
Восстановление БД... те же грабли по новым местам...
    #39696499
bid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bid
Гость
Melkij,
Конечно же у нас осталась вся старая папка DATA, она была заботливо сохранена на другом диске... Я снова могу ее скопировать и сделать несколько шагов назад в процессе восстановления, к сожалению самый распространенный способ - остановить службу, вернуть старую базу на место новой и снова запустить у нас не получился., так же как и указание нового пути для старой папки data в реестре - служба не стартовала. И очень странная ситуация - в старой папке pg_xlog - пусто, вручную удалять не должны были, была операция переноса, pg_resetxlog -х, -о, делали по данным из файла pg_controldata...

Благодарю, за ответ! Могут быть еще идеи? Попробую посмотреть что можно сделать с таблицами...
...
Рейтинг: 0 / 0
Восстановление БД... те же грабли по новым местам...
    #39696504
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bidMelkij,
Конечно же у нас осталась вся старая папка DATA, она была заботливо сохранена на другом диске... Я снова могу ее скопировать и сделать несколько шагов назад в процессе восстановления, к сожалению самый распространенный способ - остановить службу, вернуть старую базу на место новой и снова запустить у нас не получился., так же как и указание нового пути для старой папки data в реестре - служба не стартовала. И очень странная ситуация - в старой папке pg_xlog - пусто, вручную удалять не должны были, была операция переноса, pg_resetxlog -х, -о, делали по данным из файла pg_controldata...

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

Если не было сбоя в файловой системе то в старой папке pg_xlog пусто быть НЕ МОЖЕТ.
Если же сбой файловой системы был - то при потере pg_xlog всего вы базу в ЦЕЛОСТНОМ виде не восстановите.
Но отдельные таблицы может и получится в возможно поврежденном виде вытащить.
А вот весь 1С кластер в пригодном для работы 1С без плясок виде - вряд ли.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
4 сообщений из 4, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Восстановление БД... те же грабли по новым местам...
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]