Как исправить ошибку «the database system is starting up» и падение службы PostgreSQL для 1С после перезагрузки?

При аварийном завершении работы сервера или некорректной перезагрузке операционной системы Windows системные администраторы часто сталкиваются с ситуацией, когда служба СУБД PostgreSQL отказывается запускаться. В системном журнале Windows фиксируется сообщение Timed out waiting for server startup, а в журнале самой СУБД появляется запись FATAL: the database system is starting up. Если службу все же удается поднять, пользователи платформы 1С:Предприятие могут получать критические ошибки вида XX000: ERROR: tuple concurrently updated при попытке войти в информационные базы.

Разберем детально физику возникновения этих сбоев, пошаговые методы безопасного восстановления работы кластера баз данных и способы предотвращения подобных аварий в будущем.

Причины сбоя запуска и возникновения сопутствующих ошибок

Проанализируем, что происходит с базой данных в момент внезапной перезагрузки:

1. Таймаут восстановления при старте службы Windows. При аварийном отключении питания или сбросе ОС СУБД не успевает сбросить «грязные» страницы памяти на диск. При следующем старте PostgreSQL автоматически запускает процедуру наката транзакционных логов (REDO / WAL-журналов), восстанавливая целостность данных. Пока идет этот процесс, СУБД находится в режиме инициализации и возвращает статус the database system is starting up. Диспетчер служб Windows (Service Control Manager) по умолчанию ожидает ответ от службы всего 30 секунд. Если объем журналов велик или дисковая подсистема перегружена, Windows принудительно прерывает процесс СУБД по таймауту, не давая ему завершить восстановление.
2. Коллизия «tuple concurrently updated» при старте сервера 1С. При подключении к базе данных кластер 1С выполняет инициализацию служебных функций (например, VASSN, функций преобразования типов и сортировки). Если служба сервера 1С стартует одновременно с PostgreSQL или пытается выполнить эти действия в несколько рабочих потоков (rphost), параллельные команды CREATE OR REPLACE FUNCTION обращаются к одной строке в системном каталоге pg_proc. Это приводит к блокировке и ошибке параллельного обновления кортежа.

Шаг 1. Ручной запуск восстановления кластера в обход службы Windows

Чтобы операционная система не убивала процесс СУБД раньше времени, выполним процедуру наката журналов вручную через утилиту управления pg_ctl под системным пользователем postgres.

Откроем командную строку от имени администратора и перейдем к каталогу утилит PostgreSQL:

cd "C:\Program Files\PostgreSQL\9.4.2-1.1C\bin"
pg_ctl.exe -D "C:\PostgreSQL\data" start

После запуска необходимо непрерывно отслеживать текстовые логи в каталоге data\pg_log. Мы должны дождаться строки:

LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at ...
LOG: redo done at ...
LOG: database system is ready to accept connections

Как только сервер перейдет в рабочий режим, корректно остановим его командой:

pg_ctl.exe -D "C:\PostgreSQL\data" stop

Теперь процедура REDO завершена, и штатная служба Windows сможет стартовать без превышения стандартного времени ожидания.

Шаг 2. Увеличение системного таймаута ожидания служб в Windows

Чтобы в дальнейшем при непредвиденных сбоях служба не падала по таймауту, увеличим допустимое время отклика для диспетчера служб Windows через системный реестр:

1. Откроем редактор реестра (regedit).
2. Перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.
3. Найдем или создадим параметр типа DWORD (32 бита) с именем ServicesPipeTimeout.
4. Установим значение в десятичной системе, равное 120000 (что соответствует 120 секундам / 2 минутам) или 180000 (3 минуты).

Шаг 3. Изоляция базы данных и устранение ошибки «tuple concurrently updated»

Если после старта СУБД в базах 1С возникает ошибка XX000: ERROR: tuple concurrently updated на функциях вроде public.VASSN, выполним следующие действия:

1. Остановим службу сервера 1С:Предприятия (1C:Enterprise 8.3 Server Agent), чтобы исключить множественные одновременные попытки инициализации служебных структур.
2. Запустим утилиту pgAdmin или подключимся к проблемным базам через консольный клиент psql монопольно.
3. Выполним регламентное обслуживание системных каталогов для очистки зависших версий строк и перестроения индексов:

-- Перестроение системных индексов базы
REINDEX SYSTEM имя_базы_данных;

-- Очистка и дефрагментация системного каталога процедур и функций
VACUUM FULL pg_catalog.pg_proc;

-- Полное регламентное обслуживание базы данных
VACUUM FULL ANALYZE;

После завершения обслуживания системных каталогов запустим службу сервера 1С:Предприятия. Первый вход в каждую информационную базу желательно выполнить через конфигуратор или в режиме «1С:Предприятие» в один пользовательский сеанс, чтобы служебные функции успешно обновились без конкуренции потоков.

Шаг 4. Аварийный сброс журнала предзаписи WAL (крайняя мера)

Если файлы WAL-журналов были физически повреждены при сбое и сервер категорически отказывается подниматься даже вручную, выдавая ошибки контрольных сумм в логах, применяется утилита сброса транзакционного лога. Внимание: перед этой операцией обязательно создадим полную копию каталога data.

В зависимости от версии PostgreSQL выполним команду в консоли:

-- Для версий PostgreSQL 9.6 и старее:
pg_resetxlog.exe -f "C:\PostgreSQL\data"

-- Для версий PostgreSQL 10 и новее:
pg_resetwal.exe -f "C:\PostgreSQL\data"

После принудительного сброса логов сервер запустится, однако возможны логические нарушения ссылочной целостности. Поэтому сразу после старта необходимо выгрузить информационную базу в файл выгрузки (.dt) средствами конфигуратора 1С и загрузить ее в заново созданную чистую базу данных.

Шаг 5. Оптимизация настроек PostgreSQL для предотвращения повреждений

Чтобы минимизировать время восстановления после сбоев питания и исключить повреждение структуры страниц данных, проверим файл конфигурации postgresql.conf:

1. Параметры надежности записи: параметры fsync = on и full_page_writes = on должны быть обязательно включены. Отключение full_page_writes ради мнимого прироста скорости приводит к фатальному повреждению страниц данных при внезапной перезагрузке.
2. Частота контрольных точек: настроим параметры сброса грязных страниц:
   Скопировать код

   
   checkpoint_timeout = 15min
   checkpoint_completion_target = 0.9
   max_wal_size = 4GB
   min_wal_size = 1GB
   

   Это позволит равномерно распределять нагрузку на дисковую подсистему и держать объем журналов, требующих наката при аварии, в прогнозируемых пределах.
3. Зависимость служб: в диспетчере служб Windows рекомендуется настроить запуск службы сервера 1С с задержкой или установить для нее явную зависимость от службы PostgreSQL, чтобы исключить подключение рабочих процессов rphost к непрогретой СУБД.