← На главную

Аварийное отключение электроэнергии — один из самых опасных сценариев для серверов баз данных. В такой ситуации файловая система может не успеть зафиксировать изменения, что приводит к повреждению журналов транзакций и системных файлов PostgreSQL. В результате при попытке запуска службы администратор видит бесконечный статус "the database system is starting up", а в логах красуется фатальная ошибка доступа к транзакциям.

В этой статье мы подробно проанализируем ситуацию, когда СУБД PostgreSQL (версии 9.4–10) отказывается стартовать, разберем типичные ошибки «спасения» данных и определим правильный алгоритм действий для восстановления работоспособности баз 1С:Предприятие.

Краткий анализ симптомов и логов

Рассмотрим типичную картину лог-файла в такой ситуации. Если база не поднимается, первым делом заглянем в папку pg_log. Мы можем увидеть следующие записи:

FATAL: could not access status of transaction 3
DETAIL: Could not open file "pg_xact/0000": No such file or directory.

Проанализируем это сообщение. Ошибка означает, что СУБД при старте пытается провести процедуру crash recovery (восстановление после сбоя), но не находит критически важного файла, в котором хранится информация о статусах завершенности транзакций. В версиях PostgreSQL до 10.0 эта директория называлась pg_clog, в более новых — pg_xact. Отсутствие файла 0000 блокирует запуск всей системы.

Разбор критических ошибок администратора

Прежде чем перейти к правильным решениям, разберем действия, которые категорически нельзя совершать (на основе реального опыта коллег):

1. Переустановка СУБД с повышением мажорной версии. Если ваши базы работали на PostgreSQL 9.4, попытка подсунуть эти данные версии 10.5 приведет к провалу. Формат хранения данных на диске (on-disk format) у этих версий разный. Служба просто не распознает структуру файлов.
2. Копирование только папки /base. Это самая распространенная ошибка. Папка /base содержит только «сырые» данные таблиц. Вся информация о том, какая папка к какой базе относится, список пользователей, прав и связей хранится в папке /global. Без нее папка /base — это просто набор бесполезных файлов.
3. Инициализация нового кластера поверх старых данных. Попытка запустить initdb в ту же директорию, где лежат поврежденные базы, может окончательно перезаписать системные каталоги, сделав восстановление невозможным.

Решение №1: «Грязный хак» с созданием пустых файлов транзакций

Если PostgreSQL жалуется на отсутствие файла в pg_xact (или pg_clog), мы можем попробовать обмануть систему, чтобы она смогла запуститься хотя бы в режиме «только для чтения» для выгрузки дампов.

Выполним следующие шаги:

1. Остановим службу PostgreSQL, если она пытается запуститься.
2. Перейдем в каталог данных (Data directory), далее в папку pg_xact (или pg_clog для старых версий).
3. Посмотрим, какого именно файла не хватает (в логе было указано 0000).
4. Создадим в этой папке пустой файл с соответствующим именем. Важный нюанс: файл не должен быть абсолютно пустым (0 байт). Его размер должен быть кратен 8 КБ. Обычно стандартный размер составляет 256 КБ (262144 байта).
5. Заполним файл нулями. Для этого в Windows можно воспользоваться утилитой fsutil в командной строке:

fsutil file createnew C:\PostgreSQL\data\pg_xact\0000 262144

После этого попробуем запустить службу. Если база стартует, немедленно сделаем pg_dump всех критически важных баз 1С. Помните: целостность данных после такого метода не гарантирована, поэтому переиндексация и проверка средствами 1С обязательны!

Решение №2: Использование утилит аварийного сброса (pg_resetwal / pg_resetxlog)

Если создание пустых файлов не помогло, проанализируем состояние журналов предзаписи (WAL). Для этого существуют специальные утилиты, входящие в состав PostgreSQL.

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

Рассмотрим порядок действий для PostgreSQL 10 и выше:

1. Откроем командную строку от имени администратора.
2. Перейдем в папку bin установленной СУБД.
3. Запустим утилиту с флагом принудительного исполнения. Команда должна выполняться от имени пользователя, под которым работает служба (обычно postgres):

pg_resetwal.exe -f "C:\Path\To\Your\Data\Folder"

Для версии 9.4 команда будет называться иначе:

pg_resetxlog.exe -f "C:\Path\To\Your\Data\Folder"

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

Решение №3: Восстановление прав доступа

Иногда причина того, что «служба не встает», банальна — при сбое или переустановке системы «слетели» права доступа на папку с данными, особенно если она вынесена на отдельный диск.

Проанализируем права доступа:

1. Нажмем правой кнопкой на корень папки с данными (Data).
2. Вкладка «Безопасность» -> «Дополнительно».
3. Убедимся, что пользователь, от имени которого запускается служба postgres (обычно это локальный пользователь postgres), имеет права «Полный контроль» на эту папку, все подпапки и файлы.
4. Обязательно проверим наличие файла postmaster.pid в корне папки данных. Если служба НЕ запущена, а файл существует — удалим его. Он блокирует запуск, сообщая системе, что экземпляр СУБД якобы уже работает.

Особенности сборок PostgreSQL от «1С»

Нужно учитывать, что сборки PostgreSQL, предлагаемые компанией 1С, содержат специфические патчи для работы с блокировками и кодировками. Если вы решили переустановить СУБД, убедитесь, что:

• Вы используете дистрибутив с сайта ИТС или официального портала обновлений 1С.
• Параметры локализации (Collation) в новой установке полностью совпадают с теми, что были при создании баз.
• Версия платформы 1С:Предприятие поддерживает выбранную версию PostgreSQL (например, старые версии 8.3 могут иметь проблемы с Postgres 12+).

Алгоритм «правильного спасения» (Summary)

Подведем итог. Если вы столкнулись с упавшим PostgreSQL, выполним следующие действия по шагам:

1. Ничего не удаляем и не переустанавливаем в первые минуты. Делаем полную копию всей папки Data на другой носитель.
2. Проверяем логи на наличие ошибок pg_xact или pg_wal.
3. Пытаемся исправить права доступа и удалить postmaster.pid.
4. Если есть ошибки файлов — пробуем создать пустые файлы-заглушки или использовать pg_resetwal.
5. Если служба запустилась — выгружаем базы в формат .dt или через pg_dump.
6. Если ничего не помогло — разворачиваем последний актуальный бэкап в чистую папку и чистый кластер СУБД.

Помним, что единственный надежный способ избежать ночных дежурств после отключения света — это наличие исправного ИБП (UPS), который корректно завершает работу сервера, и настроенное ежедневное резервное копирование.