Часто при эксплуатации связки 1С:Предприятие и PostgreSQL системные администраторы сталкиваются с ситуацией, когда после внезапной перезагрузки сервера или отключения питания служба СУБД отказывается запускаться. При попытке ручного старта в оснастке «Службы» Windows выдает стандартное сообщение: «Служба была запущена и остановлена. Некоторые службы автоматически останавливаются, если они не используются другими службами или программами». Однако истинная причина кроется в логах самой системы и PostgreSQL — для их глубокого анализа есть инструмент мониторинга и диагностики СУБД. Проанализируем эту ситуацию и разберем пошаговый алгоритм восстановления работоспособности базы данных.
Первым делом проанализируем записи в системном журнале событий Windows (Event Viewer) или в лог-файлах PostgreSQL (обычно находятся в папке pg_log внутри каталога данных). Если вы видите следующие строки, значит, мы столкнулись с классической блокировкой процесса:
[7044] FATAL: lock file "postmaster.pid" already exists
[7044] HINT: Is another postmaster (PID 7868) running in data directory "C:/Program Files/PostgreSQL/14.5-3.1C/data"?
Timed out waiting for server startup
Эта ошибка сообщает нам, что в папке с данными data уже существует файл идентификатора процесса (PID). Рассмотрим, почему это происходит. При нормальном запуске PostgreSQL создает файл postmaster.pid, в который записывает номер своего процесса, чтобы предотвратить запуск второй копии сервера на тех же данных. При штатной остановке службы этот файл удаляется автоматически. Но если сервер «упал» или был перезагружен жестко, файл остается на диске, «обманывая» систему при следующем старте.
Прежде чем удалять файл блокировки, выясним, не запущен ли процесс, указанный в ошибке. В нашем примере система ссылается на PID 7868 или 3836. Проанализируем ситуацию в диспетчере задач:
postgres.exe.Важный момент: если вы видите активные процессы postgres.exe, это может означать, что база данных пытается выполнить автоматическое восстановление после сбоя. В сообщении 16 форума мы видим критически важную подсказку от 1С: FATAL: the database system is starting up. Это состояние означает, что СУБД жива, но занята прокруткой логов транзакций (WAL), чтобы привести базу в целостное состояние. В этом случае категорически не рекомендуется убивать процессы, нужно просто подождать.
Если мы убедились, что служба остановлена, но «висят» зависшие процессы, которые не дают СУБД стартовать заново, выполним следующие действия:
postgres.exe вручную через диспетчер задач или командой в PowerShell:
Stop-Process -Name "postgres" -Force
C:/Program Files/PostgreSQL/14.5-3.1C/data.postmaster.pid. Проанализируем его содержимое, открыв в блокноте. Там будет указан номер процесса и путь к данным.Рассмотрим случай, когда стандартная остановка через services.msc не помогает. Мы можем попытаться остановить сервер через штатную утилиту управления:
C:\Program Files\PostgreSQL\14.5-3.1C\bin>pg_ctl stop -D "C:\Program Files\PostgreSQL\14.5-3.1C\data"
Если команда возвращает failed (как в сообщении 17), это подтверждает, что файл PID содержит некорректную информацию о процессе, которого уже не существует в памяти, либо у текущего пользователя не хватает прав для взаимодействия с процессом.
В самых сложных случаях, когда после удаления PID-файла служба запускается и тут же падает с ошибкой database system was interrupted, а автоматическое восстановление не завершается успехом, приходится прибегать к утилите pg_resetwal.exe (в старых версиях pg_resetxlog).
Внимание: это опасная операция. Она сбрасывает логи транзакций и заставляет PostgreSQL игнорировать незавершенные операции. Это может привести к потере части данных 1С, которые не успели записаться на диск.
Разберем последовательность действий с этой утилитой:
data.
"C:\Program Files\PostgreSQL\14.5-3.1C\bin\pg_resetwal.exe" -f "C:\Program Files\PostgreSQL\14.5-3.1C\data"
postmaster.pid (если он появился) и пробуем запустить службу.Если проблема повторяется, выясним, не блокируется ли доступ к файлам системы. После перезагрузки сервера Windows 2012 R2 иногда могут сбрасываться права на временные папки или кэш. Проанализируем следующие настройки:
postgres или NetworkService), имеет права «Полный доступ» на папку C:\Program Files\PostgreSQL\14.5-3.1C\data.postmaster.pid в момент создания. Добавим папку с данными СУБД в исключения сканирования.Подведем итог. Чтобы успешно запустить PostgreSQL после аварии, выполним совместную работу в таком порядке:
postgres.exe. Если они потребляют ресурсы диска и процессора — ждем, идет восстановление.postmaster.pid из папки data.data нет других лишних файлов блокировки.services.msc.the database system is starting up, даем серверу время (от 5 до 60 минут в зависимости от размера базы) для завершения внутренних процедур проверки.Соблюдение этой последовательности позволяет избежать повреждения данных и восстановить работу пользователей в кратчайшие сроки.