Это сообщение предназначено прежде всего для меня лично и для нашей службы поддержки, т.к. проблема подобная описанной ниже происходит с завидной периодичностью и нужно помнить основные шаги по ее решению.
Итак, история начинается с того, что мне 30 декабря в 11-30 звонят с сообщением о том, что у одного из наших клиентов не запускается наша система, поскольку не может подключиться к базе данных (в качестве СУБД у нас используется PostgreSql версии 8.1). Люди объясняют это тем, что час назад вырубило свет и компьютер вырубился некорректно, а после включения – все перестало работать:)
Хорошие пользователи нашей системы знают, где находится кнопка пуск и знают, что в системе не двое часиков “одни с цифрами, а другие песочные”. Поэтому единственное, что удалось сделать по телефону, так это попытаться руками запустить службу СУБД, результат – служба таки не запускается. Пришлось пробрасывать на тот компьютер интернет (на компьютерах, где установлена наша система интернета быть не должно) для возможности удаленного подключения.
После подключения к удаленному компьютеру я попытался запустить службу и получил следующее сообщение: “Служба PostgreSql Database Server 8.1” на “Локальный компьютер” была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если им нечего делать, например, служба журналов и оповещений производительности”. Мда…
Проблема в том, что на тот момент это была единственная доступная информация… Логи PostgreSql пусты, записей в них никаких, в системных логах – тоже пустота.
Отладка служб – процесс не простой, поэтому многие разработчики предусматривают механизмы запуска приложения-службы, как обыкновенного консольного приложения с помощью ключей командной строки. И PostgreSql в этом плане – не исключение; для запуска нужно использовать следующую команду (Hint: эту команду можно запустить только из под неадминистративного пользователя системы, правда, если вы об этом забудете, то PostgreSql очень быстро вам об этом напомнит):
postgres -D "<postgresql data directory>"
Запускаем, и смотрим на сообщение об ошибке. В моем случае это сообщение звучало примерно так:
FATAL - bogus data in lock file "postmaster.pid"
Безусловно, мне повезло, проблема оказалась поправимой. Почему-то указанный файл оказался пустым, и мне понадобилось скопировать его содержимое из рабочего экземпляра СУБД, что не составило особого труда.
Мораль этого сообщения в том, что если база легла, или произошли какие-то другие проблемы с системой, то прежде чем переустанавливать СУБД (или систему целиком) и терять при этом все данные, нужно хотя бы попытаться выяснить в чем проблема, возможно, есть все шансы, что вам удастся восстановить работоспособность не такими радикальными способами.
З.Ы. Всех с наступающим Новым Годом и пожелания того, чтобы ваши системы были стабильными и надежными и не портили ваш сон, но даже если какие-то проблемы и возникали, то у вас всегда были наготове варианты, как с этой ситуацией справиться.
Сегодня (04.01.2010) опять легла база PosgreSql, теперь это произошло в Донецке.
ОтветитьУдалитьВ результате я с 6 до 8 пытался ее восстановить. Поднять так и не смог. Пришлось сносить СУБД и восстанавливать из резервной копии. Хорошо, что эта копия была, хотя бы месячной давности.
Что-то PostgreSql плохо переживает некорректное выключение питания компьютера.
З.Ы. В комментариях к этому сообщению буду писать о падениях Postgre-са. Любопытна статистика (которая уже сейчас начинает настораживать)!
Продолжается печальная статистика.
ОтветитьУдалить30 декабря падала еще одна база данных, в этот раз - в Семфирополе.
Итог, не менее 3-х упавших СУБД за неделю. Вполне возможно, что были еще случаи, но мне об этом не сообщили.
Статистика пугает.
Можно воспользоваться утилитой runas, для того чтобы запустить комаду от имени другого пользователя, не переключая учетные записи.
ОтветитьУдалитьrunas /user:username "C:\PostgreSQL\9.0\bin\postgres -D "C:\PostgreSQL\9.0\data""
@vaychik: спасибо!
ОтветитьУдалить