|
Восстановление БД... те же грабли по новым местам...
|
|||
---|---|---|---|
#18+
Доброго времени суток, уважаемые! Проблема стара как мир, но поиск не по форуму не по инету прямого результата не дал, либо глаза уже не видят. Ос 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 Подскажите есть ли шансы вернуть БД в рабочий вид? Если да то какими действиями? Если необходима дополнительная информация напишите, желательно сразу где посмотреть... Заранее благодарю всех кто откликнется с дельным советом! ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2018, 20:54 |
|
Восстановление БД... те же грабли по новым местам...
|
|||
---|---|---|---|
#18+
bid, нет. Шансов нет. После pg_resetxlog консистентное состояние базы восстановить практически нереально. Это специальная утилита целью которой является именно сломать всё. Если знаете что куда и как в базе пишет это 1с - попытайтесь достать с консольного psql copy запросами отдельные таблички и анализируйте, что из этого правдоподобно, а что нарушает логику данных. Какие копии PGDATA есть? Или вы были достаточно смелы, чтобы так и не сделать копию? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2018, 21:24 |
|
Восстановление БД... те же грабли по новым местам...
|
|||
---|---|---|---|
#18+
Melkij, Конечно же у нас осталась вся старая папка DATA, она была заботливо сохранена на другом диске... Я снова могу ее скопировать и сделать несколько шагов назад в процессе восстановления, к сожалению самый распространенный способ - остановить службу, вернуть старую базу на место новой и снова запустить у нас не получился., так же как и указание нового пути для старой папки data в реестре - служба не стартовала. И очень странная ситуация - в старой папке pg_xlog - пусто, вручную удалять не должны были, была операция переноса, pg_resetxlog -х, -о, делали по данным из файла pg_controldata... Благодарю, за ответ! Могут быть еще идеи? Попробую посмотреть что можно сделать с таблицами... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2018, 21:50 |
|
Восстановление БД... те же грабли по новым местам...
|
|||
---|---|---|---|
#18+
bidMelkij, Конечно же у нас осталась вся старая папка DATA, она была заботливо сохранена на другом диске... Я снова могу ее скопировать и сделать несколько шагов назад в процессе восстановления, к сожалению самый распространенный способ - остановить службу, вернуть старую базу на место новой и снова запустить у нас не получился., так же как и указание нового пути для старой папки data в реестре - служба не стартовала. И очень странная ситуация - в старой папке pg_xlog - пусто, вручную удалять не должны были, была операция переноса, pg_resetxlog -х, -о, делали по данным из файла pg_controldata... Благодарю, за ответ! Могут быть еще идеи? Попробую посмотреть что можно сделать с таблицами... Если не было сбоя в файловой системе то в старой папке pg_xlog пусто быть НЕ МОЖЕТ. Если же сбой файловой системы был - то при потере pg_xlog всего вы базу в ЦЕЛОСТНОМ виде не восстановите. Но отдельные таблицы может и получится в возможно поврежденном виде вытащить. А вот весь 1С кластер в пригодном для работы 1С без плясок виде - вряд ли. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2018, 21:54 |
|
|
start [/forum/topic.php?fid=53&tid=1995608]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 132ms |
0 / 0 |