Крэш базы со счастливым концом v8.1

Вчера у нас под конец дня грохнулась информационная база. Совершенно реально!!! Сразу посыпались звонки от пользователей, дескать почему-то выбило из программы, а при попытке повторного захода программа выдавала "Информационная база разрушена"!!!
(1С8.1 + PostgreSQL8.1+Fedora 4)

Мы конечно же делаем резервные копии каждую ночь, но это произошло под конец дня!!! Работа всего дня потеряна??!!

Я срочно накатил последнюю копию и позвонил пользователям, чтобы восстанавливали свои документы за день. Каково же было моё удивление, когда пользователи сообщили, что все документы дня никуда не исчезали 8()

Что я неправильно делаю? Подробности прилагаю.

Вчера у нас под конец дня грохнулась информационная база. Реально. Сразу посыпались звонки от пользователей, дескать почему-то выбило из программы, а при попытке повторного захода программа выдавала «Информационная база разрушена»!!!
У нас стоит серверная 1С8.1, СУБД PostgreSQL8.1, ОС Fedora Core 4.

Потом уже я изучил /var/log/messages и понял, что системе в критический момент не хватило памяти и она просто выключила самый прожорливый процесс, то есть postmaster (собственно главный процесс PostgreSQL) во время исполнения критических операций. После этого мы начали расследование, причин и так далее, это уже отдельная тема. Самое интересное в другом!

Мы конечно же делаем резервные копии. Мы делаем их средствами СУБД, то есть юзаем pg_dump, который запускается каждую ночь. Но форс-мажор произошёл под конец дня!!! Работа всего дня потеряна???!!

Я срочно поставил накатываться последнюю копию дампа БД и позвонил пользователям, чтобы готовились восстанавливать свои документы за день. Сейчас я жалею, что из-за срочности не поглядел даже состояние СУБД, были ли вообще базы на месте или нет, или грохнулись только таблицы, или что там вообще было.

Каково же было моё удивление, когда утром пользователи сообщили, что все документы дня никуда не исчезали 8()!!!!

Из этого я делаю следующие выводы:

1. Если 1С говорит, что ИБД разрушена — вполне возможно сами данные живы, просто грохнулись какие-то метаданные
2. Эти грохнутые метаданные сидят в СУБД, иначе бы не исправлялись средствами СУБД
3. Восстановление БД PostgreSQL средствами pg_restore не уничтожает старой БД, даже если перед ним сделать drop_db + create_db !!

Что я неправильно делаю?? Жду комментов как из печки пирога!

———————————
2008-08-25

Прошло некоторое время, многое успокоилось и появились новые факты.

1. В результате серии экспериментов мне не удалось повторить ситуации с восстановлением из лога транзакций после восстановления из дампа. Да и больше похоже всё это на бред, ибо восстановление базы должно было тоже попасть в лог транзакций 🙂 и соответсвенно потом должно было накатиться.

2. Судя по проявившимся позднее деталям происшествия, можно говорить, что восстановление велось в неправильную-левую базу. То есть родная база не была задета операциями восстановления.

ИБД восстановилась как-то сама собой, без бекапов.
Короче, сам себя запутал 🙂

Предлагаю тему считать закрытой, за отсутствием информации о происшествии.

6 Comments

  1. German

    1. Да.

    2. Как и все данные.

    3. Бред.

    Видимо бекап у Вас был полный + транзакции делались с 9-18 каждый час(или другой промежуток) … при восстановлении он предлагает последнюю актуальную. Вот вы ее и жахнули.

    Reply
  2. MaratL

    Согласен насчёт бреда. Но странно.

    Да, бекап был полный. Но pg_restore запросов на восстановление транзакций не давал. Получается он сделал всё сам? Инсталляция PostgreSQL дефолтная.

    Пойду курить мануал в сторону лога транзакций

    Reply
  3. CheBurator

    тут главное — не суетиться.. конец дня.. фигли митуситься — доработать как есть вручную, а потом вечер-ночь восстанавливать…

    ???

    Reply
  4. MaratL

    По-русски ничего не нашёл. Только по-английски

    http://www.postgresql.org/docs/8.1/interactive/wal-internals.html

    Насколько я понял — сервер сам следит за соответствием БД логу транзакций и в случае несоответствия чек-поинтов догоняет базу. Что скорее всего и произошло в моём случае после восстановления дампа.

    Герман, похоже, прав.

    (3) Насчёт суеты согласен. Всё равно пока восстанавливали рабочий день кончился 🙂

    Reply
  5. tango

    прикольно это:

    «в критический момент не хватило памяти и она просто выключила самый прожорливый процесс, то есть postmaster (собственно главный процесс PostgreSQL)»

    Reply
  6. MaratL

    (5) Просто я его мальца нагрузил ..

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *