Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Восстановление БД... те же грабли по новым местам... / 4 сообщений из 4, страница 1 из 1
31.08.2018, 20:54
    #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
31.08.2018, 21:24
    #39696493
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Восстановление БД... те же грабли по новым местам...
bid,

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

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

Благодарю, за ответ! Могут быть еще идеи? Попробую посмотреть что можно сделать с таблицами...
...
Рейтинг: 0 / 0
31.08.2018, 21:54
    #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
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Восстановление БД... те же грабли по новым местам... / 4 сообщений из 4, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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