Я пытаюсь запустить Postgres 9.2.4 в качестве службы в Windows 7. После установки postgres служба работает нормально. Однако после установки postgres в качестве сервера для другой программы служба перестала работать. Когда я пытаюсь запустить сервис сейчас, я получаю сообщение о том, что:
"Служба postgresql-x64-9.2 - PostgreSQL Server 9.2 на локальном компьютере Компьютер начал, а затем остановился. Некоторые службы автоматически останавливаются, если они не используются другими службами или программами".
Когда я пытаюсь запустить программу, которая должна использовать сервер базы данных, я получаю эту ошибку:
"Проблема возникла при попытке войти в систему или создать производственной базы данных. Подробности: не удалось подключиться к серверу; Мог не подключаться к удаленному разъему. Приложение должно теперь закрыть"
Я также столкнулся с этой ошибкой один раз при открытии одной и той же программы:
"Проблема возникла при попытке войти в систему или создать производственной базы данных. Подробности: FATAL: не удалось загрузить pg_hba.conf. приложение должно теперь закрыть."
Я попытался запустить службу, зарегистрированную как локальную системную учетную запись, а также мою собственную учетную запись (в свойствах свойств postgres) безрезультатно. Я также попытался перезагрузить компьютер. После многих проблем в Интернете, я узнал, что хорошо проверить файл pg_log. Вот содержание последней записи pg_log:
2013-05-29 14:59:45 MDT LOG: database system was interrupted; last known up at 2013-05-29 14:58:01 MDT 2013-05-29 14:59:45 MDT LOG: database system was not properly shut down; automatic recovery in progress 2013-05-29 14:59:45 MDT LOG: record with zero length at 0/175BB98 2013-05-29 14:59:45 MDT LOG: redo is not required 2013-05-29 14:59:45 MDT LOG: database system is ready to accept connections 2013-05-29 14:59:45 MDT LOG: autovacuum launcher started 2013-05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:09:03 MDT LOG: received fast shutdown request 2013-05-29 15:09:03 MDT LOG: aborting any active transactions 2013-05-29 15:09:03 MDT LOG: autovacuum launcher shutting down 2013-05-29 15:09:03 MDT LOG: shutting down 2013-05-29 15:09:03 MDT LOG: database system is shut down
Кажется, что возникают проблемы с файлом pg_hba.conf, который выглядит следующим образом:
Local all all trust host all all 127.0.0.1 255.255.255.255 trust host all all 0.0.0.0 0.0.0.0 trust
В соответствии с многочисленными предложениями в Интернете я попытался изменить верхнюю строку на несколько различных альтернатив (все хосты all trust/host all 127.0.0.1/32 trust/host all 192.168.0.100/24 trust и т.д.). Это имело смысл для меня, поскольку в файле журнала говорилось, что локальные соединения не поддерживаются postgres и также указывают на эту строку. Однако ни одно из моих изменений не повлияло. Я попытался перезагрузить свой компьютер после каждого изменения, но ничего не изменилось.
Когда я искал примеры того, как обычно выглядит файл pg_hba.conf, примеры выглядели немного отличными от моего файла. Я заметил, что в файле программы PostgreSQL в дополнение к pg_hba.conf был также файл 20130529-150444-old-pg_hba.conf, который намного больше напоминал примеры, которые я нашел в Интернете. Этот файл имеет несколько строк комментариев до этих последних нескольких строк:
# TYPE DATABASE USER ADDRESS METHOD # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #host replication postgres 127.0.0.1/32 md5 #host replication postgres::1/128 md5
Я надеялся, что это был оригинальный файл pg_hba.conf, и если я заменил новый файл содержимым старого, postgres начнут работать снова. Нет такой удачи. Я надеялся, что в файле pg_log будет зарегистрировано больше файлов ошибок, чтобы узнать, исчезла ли ранее заявленная ошибка или что-то изменилось, но больше файлов не было зарегистрировано.
Я искал онлайн-службу в течение нескольких дней, и ничего, что я нашел, не сработало. Извините за такой длинный вопрос, но я хотел быть основательным и включить всю соответствующую информацию. Я был бы признателен, если бы кто-нибудь мог пролить свет на эту проблему или предложить предложения.
pg_ctl init [ -s ] [ -D datadir ] [ -o initdb-options ]
pg_ctl start [ -w ] [ -t секунды ] [ -s ] [ -D datadir ] [ -l имя_файла ] [ -o параметры ] [ -p path ] [ -c ]
pg_ctl stop [ -W ] [ -t секунды ] [ -s ] [ -D datadir ] [ -m s | f | i ]
pg_ctl restart [ -w ] [ -t секунды ] [ -s ] [ -D datadir ] [ -c ] [ -m s | f | i ] [ -o параметры ]
pg_ctl reload [ -s ] [ -D datadir ]
pg_ctl status [ -D datadir ]
pg_ctl promote [ -s ] [ -D datadir ]
pg_ctl kill signal_name process_id
pg_ctl register [ -N servicename ] [ -U имя_пользователя ] [ -P пароль ] [ -D datadir ] [ -S a | d ] [ -w ] [ -t секунды ] [ -s ] [ -o параметры ]
pg_ctl unregister [ -N servicename ]
Сервер запускается в режиме start . Процесс работает в фоновом режиме, а стандартный ввод связывается с /dev/null (или nul под управлением Windows). По умолчанию в Unix-подобных системах вывод и ошибки сервера пишутся в устройство стандартного вывода (не ошибок) pg_ctl . Вывод pg_ctl следует перенаправить в файл или процесс, например, приложение ротации журналов rotatelogs ; в ином случае, postgres будет писать вывод в управляющий терминал (в фоновом режиме) и останется в группе процессов оболочки. В Windows вывод и ошибки сервера по умолчанию перенаправляются в терминал. Это поведение можно изменить и направить вывод сервера в файл, добавив ключ -l . Мы рекомендуем использовать ключ -l или перенаправлять вывод.
Чтобы остановить сервер, используется stop . Остановить можно в трёх режимах, задаваемых флагом -m . По умолчанию используется режим "Smart" , который ожидает завершения всех активных клиентских соединений и удалённых процессов резервирования. Если сервер работает в режиме горячего резервирования, то восстановление и потоковая репликация будут остановлены, как только все клиентские сессии завершаться. Режим "Fast" не ожидает закрытия клиентских сессий и прерывает удалённые процессы резервирования. Все активные транзакции откатываются, а клиенты принудительно отсоединяются, после чего сервер останавливается. Режим "Immediate" незамедлительно прерывает все процессы и останавливает сервер, что приводит на следующем старте к необходимости восстановления после сбоя.
Для остановки с последующим стартом сервера используется restart . При этом доступны флаги команды postgres . restart может не отработать, если при старте сервера в командной строке был указан относительный путь к каталогу хранения данных.
Чтобы перечитать конфигурацию (postgresql.conf , pg_hba.conf и т. д.), используется reload , при этом процесс postgres получает системный сигнал SIGHUP . Это позволяет применить изменения без полного рестарта сервера.
Чтобы проверить статус кластера, используется status . Если кластер запущен, то будет выведен PID процесса, а также команда с использованными при запуске аргументами. Если кластер остановлен, то процесс вернёт статус завершения 3. Если не указан каталог хранения данных, то процесс вернёт статус завершения 4.
Чтобы перевести резервный сервер в режим основного, используется promote . При этом сервер прекращает работу в режиме восстановления и начинает работать в режиме чтения-записи.
Чтобы послать сигнал процессу, используется kill . Это особенно применимо в среде Microsoft Windows , которая не имеет в оснастке команды kill . Чтобы посмотреть список доступных сигналов, обратитесь к справке --help .
Для регистрации в качестве системной службы под управлением Microsoft Windows , используется register . Флаг -S устанавливает режим запуска службы, либо "auto" (на старте ОС), либо "demand" (по запросу).
Чтобы удалить зарегистрированную службу в Microsoft Windows , используется unregister .
Параметры
C
--core-file
На платформах, где это поддерживается, сервер будет пытаться фиксировать снимки памяти при авариях. Это позволяет диагностировать и предотвращать потенциальные проблемы в будущем. -D datadir
--pgdata datadir
Указывает размещение конфигурационных файлов кластера. Если не указано, используется значение переменной окружения PGDATA . -l имя_файла
--log имя_файла
Выводит данные журнала в filename
. Файл создаётся, если он ещё не существует. При этом umask
выставляется в 077, что предотвращает доступ других пользователей к этому файлу. -m режим
--mode режим
Устанавливает режим остановки кластера. mode принимает значения smart , fast , или immediate , либо по первой букве каждого из доступных значений, например, s . Если флаг опущен, то используется smart . -o параметры
Указывает флаги, которые будут переданы в postgres .
Значение необходимо обрамлять одинарными или двойными кавычками, чтобы гарантировать целостность группы. -o initdb-options
Указывает флаги, которые будут переданы в initdb .
Значение необходимо обрамлять одинарными или двойными кавычками, чтобы гарантировать целостность группы. -p path
Указывает размещение приложения postgres . По умолчанию используется тот же путь, по которому находится pg_ctl , либо, если это не удалось, то берётся путь инсталляции. Применять этот параметр чаще всего необходимости нет, кроме нестандартных ситуаций.
init принимает параметры аналогично initdb . -s
--silent
Выводить лишь ошибки, без сообщений информационного характера. -t
--timeout
Максимальное время (в секундах) ожидания запуска или остановки сервера. По умолчанию это 60 секунд. -V
--version
Выводит версию pg_ctl и прерывает выполнение. -w
Ожидает завершения запуска или остановки. Это является режимом по умолчанию для операций остановки, но не запуска. На этапе запуска pg_ctl непрерывно пытается подключиться к серверу. На этапе остановки pg_ctl проверяет наличие PID файла. Этот параметр позволяет установить ввод контрольного слова для SSL на старте сервера. pg_ctl возвращает код завершения, основываясь на результате операций запуска или остановки. -W
Игнорировать ожидание завершения запуска или остановки сервера. Это поведение используется по умолчанию для режимов запуска и повторного запуска. -?
--help
Вывести справку по команде pg_ctl и прервать выполнение.
Параметры, специфичные для Windows
N servicename
Имя регистрируемой системной службы. Оно используется в качестве системного и отображаемого значения. -P пароль
Пароль пользователя, стартующего службу. -S тип запуска
Тип запуска системной службы. Может принимать значения: auto , или demand , либо быть представлен первой буквой названия каждого приведённого значения. По умолчанию используется auto . -U имя_пользователя
Имя пользователя, от имени которого будут запущена служба. Для доменных пользователей необходимо использовать нотацию DOMAIN\username .
Это сообщение предназначено прежде всего для меня лично и для нашей службы поддержки, т.к. проблема подобная описанной ниже происходит с завидной периодичностью и нужно помнить основные шаги по ее решению.
Итак, история начинается с того, что мне 30 декабря в 11-30 звонят с сообщением о том, что у одного из наших клиентов не запускается наша система, поскольку не может подключиться к базе данных (в качестве СУБД у нас используется PostgreSql версии 8.1). Люди объясняют это тем, что час назад вырубило свет и компьютер вырубился некорректно, а после включения – все перестало работать:)
Хорошие пользователи нашей системы знают, где находится кнопка пуск и знают, что в системе не двое часиков “одни с цифрами, а другие песочные”. Поэтому единственное, что удалось сделать по телефону, так это попытаться руками запустить службу СУБД, результат – служба таки не запускается. Пришлось пробрасывать на тот компьютер интернет (на компьютерах, где установлена наша система интернета быть не должно) для возможности удаленного подключения.
После подключения к удаленному компьютеру я попытался запустить службу и получил следующее сообщение: “Служба PostgreSql Database Server 8.1” на “Локальный компьютер” была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если им нечего делать, например, служба журналов и оповещений производительности”. Мда…
Проблема в том, что на тот момент это была единственная доступная информация… Логи PostgreSql пусты, записей в них никаких, в системных логах – тоже пустота.
Отладка служб – процесс не простой, поэтому многие разработчики предусматривают механизмы запуска приложения-службы, как обыкновенного консольного приложения с помощью ключей командной строки. И PostgreSql в этом плане – не исключение; для запуска нужно использовать следующую команду (Hint: эту команду можно запустить только из под неадминистративного пользователя системы, правда, если вы об этом забудете, то PostgreSql очень быстро вам об этом напомнит):
postgres -D "
Запускаем, и смотрим на сообщение об ошибке. В моем случае это сообщение звучало примерно так:
FATAL - bogus data in lock file "postmaster.pid"
Безусловно, мне повезло, проблема оказалась поправимой. Почему-то указанный файл оказался пустым, и мне понадобилось скопировать его содержимое из рабочего экземпляра СУБД, что не составило особого труда.
Мораль этого сообщения в том, что если база легла, или произошли какие-то другие проблемы с системой, то прежде чем переустанавливать СУБД (или систему целиком) и терять при этом все данные, нужно хотя бы попытаться выяснить в чем проблема, возможно, есть все шансы, что вам удастся восстановить работоспособность не такими радикальными способами.
З.Ы. Всех с наступающим Новым Годом и пожелания того, чтобы ваши системы были стабильными и надежными и не портили ваш сон, но даже если какие-то проблемы и возникали, то у вас всегда были наготове варианты, как с этой ситуацией справиться.
