Крэш базы со счастливым концом v8.1
07.08.08
База данных - Инструменты администратора БД
Вчера у нас под конец дня грохнулась информационная база. Совершенно реально!!! Сразу посыпались звонки от пользователей, дескать почему-то выбило из программы, а при попытке повторного захода программа выдавала "Информационная база разрушена"!!!
(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 !!
Что я неправильно делаю?? Жду комментов как из печки пирога!
У нас стоит серверная 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. Судя по проявившимся позднее деталям происшествия, можно говорить, что восстановление велось в неправильную-левую базу. То есть родная база не была задета операциями восстановления.
ИБД восстановилась как-то сама собой, без бекапов.
Короче, сам себя запутал :)
Предлагаю тему считать закрытой, за отсутствием информации о происшествии.
2008-08-25
Прошло некоторое время, многое успокоилось и появились новые факты.
1. В результате серии экспериментов мне не удалось повторить ситуации с восстановлением из лога транзакций после восстановления из дампа. Да и больше похоже всё это на бред, ибо восстановление базы должно было тоже попасть в лог транзакций :) и соответсвенно потом должно было накатиться.
2. Судя по проявившимся позднее деталям происшествия, можно говорить, что восстановление велось в неправильную-левую базу. То есть родная база не была задета операциями восстановления.
ИБД восстановилась как-то сама собой, без бекапов.
Короче, сам себя запутал :)
Предлагаю тему считать закрытой, за отсутствием информации о происшествии.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.