PostgreSQL Error 57P03: the database system is starting up / cannot_connect_now
- Ошибка подключения:
FATAL: the database system is starting up (SQLSTATE 57P03)илиthe database system is in recovery mode. - Клиенты 1С и сервисы не могут установить TCP соединение с СУБД.
- Реплика в режиме Hot Standby отказывает в подключениях до достижения точки консистентности.
1. Проверка статуса запуска в логах PostgreSQL
tail -f /var/log/postgresql/postgresql-15-main.logИщите строки вида: LOG: redo in progress, consistent recovery state reached at...
2. Проверка доступности подключений на реплике (Hot Standby)
Убедитесь, что в postgresql.conf включен параметр:
hot_standby = on
hot_standby_feedback = on3. Оценка оставшегося объема WAL для проигрывания
# Текущая позиция replay на ведомом узле
SELECT pg_last_wal_replay_lsn();4. Ускорение процедуры восстановления при старте
Для ускорения чтения WAL с диска увеличьте производительность I/O или настройте превентивный сброс грязных страниц на мастере:
-- На основном узле:
ALTER SYSTEM SET max_wal_size = '32GB';
ALTER SYSTEM SET checkpoint_completion_target = 0.9;
SELECT pg_reload_conf();Частые вопросы (FAQ)
Сколько времени может сохраняться ошибка 57P03?
Время зависит от объема не зафиксированных в checkpoint журналов WAL. Если база аварийно выключилась во время интенсивной записи, проигрывание REDO может занять от нескольких минут до часа.
Можно ли форсировать открытие базы без ожидания окончания REDO?
Нет. Принудительный пропуск восстановления приведет к физическому повреждению структуры таблиц и индексов.
Почему 57P03 появляется на реплике при старте?
Реплика не принимает подключения до тех пор, пока не дойдет до минимальной консистентной точки LSN, полученной от мастера.
Помогает ли увеличение max_wal_size избежать долгих стартов?
Наоборот: слишком большой max_wal_size увеличивает время восстановления при аварии. Оптимизируйте checkpoint_timeout и держите баланс между I/O и временем старта.