Ошибка PostgreSQL FATAL: the database system is in recovery mode

Краткая рекомендация MoscowSoft"

Если при попытке зайти в базы 1С после какого-то неожиданного события, например, перезапуска сервера СУБД, вы получаете ошибку "FATAL: the database system is in recovery mode", проверьте, есть ли место на диске, где хранятся базы PostgreSQL, есть ли место на диске операционной системы. Есть ли свободная оперативная память. Если все хорошо, посмотрите каталог logs внутри каталога PostgreSQL. В самом новом файле этого каталоге самые последние записи будут выглядеть примерно так:

...
2026-06-13 09:33:40.588 MSK [9192] FATAL: the database system is in recovery mode
2026-06-13 09:33:40.594 MSK [10452] FATAL: the database system is in recovery mode
2026-06-13 09:33:40.609 MSK [13752] FATAL: the database system is in recovery mode
2026-06-13 09:33:40.618 MSK [8468] FATAL: the database system is in recovery mode
2026-06-13 09:33:40.624 MSK [12572] FATAL: the database system is in recovery mode
2026-06-13 09:33:40.637 MSK [7632] FATAL: the database system is in recovery mode

Так вот, если с ресурсами на сервере СУБД все хорошо, то рекомендация при виде таких сообщений в логах будет простая - подождать. Происходит восстановление рабочего состояния PostgreSQL. Чем больше у вас файлов баз данных, тем дольше будет такой процесс проходить. По нашей практике - до 30 минут может занимать.

Распространенные причины ошибки the database system is in recovery mode

Сообщение об ошибке “the database system is in recovery mode” возникает, когда сервер PostgreSQL после сбоя или специальной операции находится в процессе восстановления. Основные причины включают:

• Аварийный перезапуск сервера. Если сервер завершил работу ненормально (например, из-за сбоя питания или убийства процесса), то при следующем старте PostgreSQL выполняет автоматическое восстановление по журналам транзакций (WAL). До завершения этой процедуры новые подключения блокируются сообщением FATAL.
• Недостаток ресурсов. Операционная система или сам PostgreSQL может завершить серверный процесс из-за нехватки ОЗУ (OOM-killer), либо база не сможет записывать данные на диск из-за заполнения. Например, если диск оказался полностью заполнен, при попытке записи новый серверный процесс не сможет завершить чекпойнт, и сервер перейдёт в режим восстановления.
• Режим репликации (Hot Standby). Если база настроена как резервная реплика, она постоянно находится в режиме восстановления (ожидает логи от мастера). В этом состоянии она доступна только для чтения, а любые попытки записать данные будут отвергнуты ошибкой FATAL. Чтобы выйти из режима реплики, необходимо выполнить «promotion» реплики (перевести в primary).
• Ошибки оборудования или файловой системы. Сбой диска, проблемы с файловой системой или неверные права доступа к каталогу данных могут вызвать аварийную остановку сервера и перевод его в recovery mode. В логах это может проявиться сообщениями о сбоях ввода-вывода или «PANIC».

Как определить причину

Чтобы найти конкретную причину перехода сервера в recovery mode, следует проверить логи PostgreSQL и состояние системы:

• Изучите логи сервера. Журналы PostgreSQL обычно находятся в каталоге data/pg_log или /var/log/postgresql. Посмотрите записи перед сообщением FATAL: там могут быть ошибки вида «Out of memory», «No space left on device», «PANIC» или сообщения об аварийной остановке. Это даст подсказку о том, что произошло.
• Проверьте дисковое пространство. С помощью команды системы (например, df -h) убедитесь, что на дисках достаточно свободного места. Если диск заполнен, база может не запуститься. Для оценки того, какие базы данных занимают больше всего места, выполните SQL-запрос ниже.
• Выполните SQL-запрос для оценки размера баз данных. В pgAdmin или через psql запустите этот запрос. Он покажет имена баз и их размеры в удобочитаемом формате:

  
  		SELECT
  		pg_database.datname,
  		pg_size_pretty(pg_database_size(pg_database.datname)) AS size
  		FROM pg_database
  		ORDER BY pg_database_size(pg_database.datname) DESC;

• Проверьте режим сервера. Выполните запрос SELECT pg_is_in_recovery();. Если он вернёт true, значит сервер в режиме recovery (например, как реплика). Также можно проверить наличие файлов recovery.conf или standby.signal в каталоге данных — это указывает, что сервер запущен как standby.
• Проверьте память и нагрузку. Если в логах встречаются сообщения «Out of memory: Kill process postgres», система завершила процесс из-за нехватки памяти. Проверьте текущее потребление памяти (команда free -m), загрузку CPU и сообщения ОС (команда dmesg или /var/log/syslog) на предмет OOM killer.

Что делать для исправления ошибки the database system is in recovery mode

Выявив причину сбоя, приступайте к её устранению:

1. Освободите или расширьте дисковое пространство. Если выяснилось, что диск заполнен, удалите ненужные файлы (например, старые логи, резервные копии) или расширьте том (увеличьте размер диска или добавьте дополнительный). После этого перезапустите PostgreSQL (например, командой sudo systemctl restart postgresql).
2. Устраните нехватку памяти. Если причиной стал OOM, уменьшите нагрузку на сервер и настройте параметры памяти. Закройте лишние соединения, уменьшите max_connections и work_mem, добавьте оперативной памяти или swap. Затем перезапустите сервис PostgreSQL.
3. Выйдите из режима репликации (если используется реплика). Если сервер настроен как standby и вы хотите работать с ним как с primary, выполните pg_ctl promote -D <PGDATA> от имени пользователя postgres. Это переведёт сервер из режима recovery в обычный режим. Если репликация больше не нужна, удалите или переименуйте файл recovery.conf или standby.signal и перезапустите сервер.
4. Выполните восстановление из резервной копии. Если БД повреждена или описанные методы не помогли, восстановите данные из последней рабочей резервной копии. В 1С можно использовать сохранённый дамп конфигурации или выгрузку базы. В PostgreSQL применяйте pg_restore или pg_basebackup для восстановления данных.
5. Проверьте целостность и оптимизируйте БД. После запуска проверьте данные (например, с помощью pg_amcheck) и выполните VACUUM для очистки мусора. Убедитесь, что после восстановления файл recovery.signal удалён и сервер больше не стартует в режиме recovery. Настройте мониторинг системы, чтобы заранее получать предупреждения о заполнении диска или нехватке памяти.

Вывод и рекомендации

Ошибка FATAL: the database system is in recovery mode обычно указывает на серьёзный сбой сервера или нехватку ресурсов. Наиболее вероятные причины — переполненный диск, нехватка памяти или аварийное завершение работы PostgreSQL. Чтобы восстановить работу, сначала найдите корень проблемы (анализ логов, проверка свободного места, статус репликации), затем примените соответствующие меры: добавьте ресурсы, очистите место или восстановите данные из бэкапа. Как правило, после устранения причины достаточно перезапустить службу — и сервер успешно завершит процедуру восстановления и начнёт принимать подключения.

Подписывайтесь на рассылку MoscowSoft для получения свежих статей по PostgreSQL и 1С. Ознакомьтесь с другими материалами на сайте, например, с обзором по резервному копированию и восстановлению баз 1С. Если остались вопросы или нужна помощь в администрировании, задавайте их нашим специалистам в комментариях или службе поддержки.