← На главную

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

Анализ исходной проблемы: почему падает PostgreSQL?

Рассмотрим типичный сценарий: при попытке запуска службы в логах СУБД фиксируется ошибка database system was interrupted; last known up at.... Это сигнализирует о том, что работа базы была прервана аварийно (например, из-за отключения питания или сбоя дисковой подсистемы), и контрольная точка (checkpoint) не успела завершиться. Если при этом в папке pg_wal (или pg_xlog для старых версий) отсутствуют необходимые файлы, стандартная процедура автоматического восстановления (REDO) становится невозможной.

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

Вариант 1. Экстренный запуск «упавшей» службы (pg_resetwal)

Если папка data на месте, но служба не стартует из-за логов, проанализируем возможность использования утилиты pg_resetwal (в версиях до 10 — pg_resetxlog). Это «ядерный» метод, который принудительно сбрасывает логи транзакций и создает новую цепочку WAL.

Пошаговый алгоритм действий:

1. Сделаем полную копию всей папки data на другой диск (обязательно!).
2. Откроем командную строку от имени пользователя, под которым работает PostgreSQL.
3. Перейдем в каталог bin установленной СУБД.
4. Выполним команду очистки логов (параметр -f заставляет утилиту работать принудительно):

pg_resetwal -f "C:\Program Files\PostgreSQL\13.4-6.1C\data"

После этой операции служба может запуститься, но внимание: целостность данных не гарантирована. Часть транзакций, которые были в логах, будет потеряна. Этот метод хорош только для того, чтобы зайти в базу и выгрузить .dt файл или сделать свежий pg_dump.

Вариант 2. Восстановление из логического дампа (pg_dump)

Если у нас есть актуальные файлы бэкапа, созданные средствами pg_dump, рассмотрим наиболее надежный способ восстановления через pgAdmin 4 или консольную утилиту pg_restore.

Разберем последовательность шагов, предложенную опытными коллегами:

1. Запустим pgAdmin 4 и создадим новую пустую базу данных.
2. При создании обязательно укажем правильные параметры: Encoding — UTF8, а LC_COLLATE и LC_CTYPE — Russian_Russia.1251. Это критично для корректной работы 1С с кириллицей.
3. Нажмем правой кнопкой на созданную базу и выберем пункт Restore (Восстановить).
4. Укажем путь к файлу дампа. Если дамп был сделан в формате custom или tar, восстановление пройдет успешно.
5. Остановим службу Агента сервера 1С:Предприятие.
6. Переименуем старую (битую) базу в СУБД (например, добавив суффикс _old), а новую базу назовем именем оригинальной.
7. Запустим Агента сервера 1С.

Проблема: В Конфигуратор заходит, а в Предприятие — нет

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

1. Смещение дат в таблице _YearOffset: Платформа 1С часто хранит даты со смещением в 2000 лет. Если параметры новой базы в PostgreSQL (кодировка или региональные настройки) не совпадают с теми, что были при создании оригинала, 1С не может корректно прочитать значения из системных таблиц и падает.
2. Кэш сервера 1С: Это самая частая причина. В папке srvinfo (реестр кластера 1С) хранятся идентификаторы баз данных (GUID). При пересоздании базы в СУБД связь может нарушиться.
   Решение: Остановим службу 1С, найдем в каталоге srvinfo/reg_1541 папку с GUID-ом вашей базы и временно переместим ее. После перезапуска 1С пересоздаст кэш.
3. Несоответствие версии PostgreSQL: Пользователи часто совершают ошибку, скачивая «ванильную» версию PostgreSQL с официального сайта postgresql.org. Помните: стандартная сборка не подходит для 1С. Необходимо использовать только специальные сборки от Postgres Professional (1C Edition) или дистрибутивы с сайта releases.1c.ru. В обычных версиях отсутствуют патчи для поддержки mchar и корректных сортировок, что приводит к падению 1С при выполнении запросов.

Ошибка «Timed out waiting for server startup» на новых версиях

Если вы решили обновить версию PostgreSQL (например, на 17-ю), и служба перестала запускаться с ошибкой таймаута в системных логах Windows, проанализируем следующие факторы:

1. Остаточный файл postmaster.pid: Если база «падала», в папке data мог остаться файл postmaster.pid. Пока он существует, новая служба будет считать, что экземпляр уже запущен, и уйдет в бесконечное ожидание. Просто удалите этот файл.
2. Права доступа: Проверим, под каким пользователем запускается служба. Если это NetworkService, убедимся, что у этой учетной записи есть полные права на папку с данными.
3. Конфигурация postgresql.conf: При миграции со старых версий (например, с 13 на 17) некоторые параметры в файле конфигурации могут быть устаревшими. Рекомендуется инициализировать новую базу (initdb), а затем аккуратно переносить настройки памяти и подключений.

Резюме и рекомендации

Восстановление базы 1С на PostgreSQL требует комплексного подхода. Проанализировав опыт коллег, можно сделать вывод, что наиболее стабильным решением является:

• Использование логических бэкапов (дампов) для переноса данных в новую, чистую базу, созданную с правильными локалями.
• Обязательная очистка серверного кэша 1С после любых манипуляций с базой на уровне СУБД.
• Применение исключительно адаптированных под 1С сборок PostgreSQL.

Соблюдение этих правил позволит вам не только восстановить данные, но и обеспечить стабильную работу системы без неожиданных падений и «зависаний» пользователей.