#Что означает ошибка
Если файловая система с каталогом pg_wal заполнилась, PostgreSQL может прекращать запись и сообщать No space left on device; причинами бывают сбой архивирования, остановленная репликация и удержание WAL репликационным слотом. При аварии нельзя вручную удалять файлы pg_wal: они нужны для восстановления и согласованности базы. Сначала обеспечьте место безопасным способом и установите причину накопления.
#Как различить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Репликационный слот удерживает старые WALОтключённый подписчик или реплика не подтверждает приём данных. | В pg_replication_slots есть неактивный slot с отстающим restart_lsn; каталог растёт. | Восстановить репликацию или согласовать изменение политики удержания; не удалять слот автоматически. |
| Архивирование WAL не работаетarchive_mode включён, но archive_command или archive_library не могут сохранить файлы. | В pg_stat_archiver увеличивается failed_count, а архивные журналы показывают ошибки копирования. | Исправить место назначения архива, права или связь, сохранив цепочку резервного восстановления. |
| Низкий запас места либо высокая скорость записиБаза генерирует WAL быстрее, чем система успевает очистить старые сегменты после checkpoint. | df -h показывает критически малое место, репликация и архивирование могут быть здоровыми. | Расширить том и пересмотреть нагрузку, лимиты и контроль свободного места. |
#Пошаговая диагностика и устранение
- Сохраните признаки аварии и прекратите опасные действияПри
No space left on device, невозможности COMMIT или старта PostgreSQL откройте панель мониторинга и журнал службы. Запишите время, точную строку ошибки и состояние диска. Не перезапускайте сервер многократно и не удаляйте файлыpg_wal,pg_xact,postmaster.pidили архивы для «быстрого освобождения» — последствия могут включать невозможность восстановления. - Установите, какой том действительно заполненНа Linux войдите в обычный терминал и выполните
df -h; если сервер в контейнере или имеет отдельный том под WAL, проверьте раздел, где находится каталог данных и pg_wal, по документации развертывания. В Windows откройте «Этот компьютер» и сведения о занятом томе. Если подключение к базе доступно,SHOW data_directory;уточнит местоположение; при недостаточных правах попросите администратора. - Обеспечьте безопасный резерв свободного местаЕсли диск действительно заполнен, попросите администратора увеличить размер файловой системы или освобождать место исключительно вне каталога данных PostgreSQL — например, после подтверждения владельца переместить несвязанные старые файлы приложения на другое хранилище. Не чистите pg_wal, архив WAL или резервные копии без проверки политики восстановления. При невозможности безопасно расширить том остановите тяжёлые задания приложения и привлеките дежурного администратора.
- Когда база снова доступна, проверьте версию и параметры WALПодключитесь через psql или pgAdmin → Query Tool и выполните
SHOW server_version; SHOW archive_mode; SHOW max_wal_size; SHOW wal_keep_size;. Сохраните результаты. Важно: max_wal_size — мягкий предел, при сбое архивирования или отстающей реплике pg_wal может вырасти существенно выше него. Не уменьшайте параметры вслепую. - Посмотрите состояние архивированияВыполните
SELECT archived_count, last_archived_time, failed_count, last_failed_time FROM pg_stat_archiver;. Если failed_count растёт, проверьте журнал процесса archiver и назначение archive_command или archive_library. Не заменяйте archive_command наtrueили пустую команду «для исправления»: это нарушит цепочку восстановления до выбранной точки. - Проверьте репликационные слоты без удаленияВыполните
SELECT slot_name, slot_type, active, restart_lsn FROM pg_replication_slots;и, если разрешены права, посмотрите репликационные подключения. Если слот неактивен, выясните, нужна ли его реплика или подписчик. Удаление слота способно потребовать полной пересборки реплики или потерю данных подписчика. Решение принимает только ответственный за репликацию. - Исправьте установленную причину с сохранением восстановленияЕсли архивирование не работает, устраните ошибку хранения/сети и убедитесь, что очередные сегменты успешно архивируются. Если отстала реплика, восстанавливайте её подключение и приемлемое отставание. Для ограничения роста слотов существует max_slot_wal_keep_size, но неправильная настройка может привести к потере необходимых WAL и необходимости пересоздать реплику: планируйте её вместе с администратором.
- Проверьте работу БД и наблюдайте за свободным местомПосле устранения причины сравните df -h, архивную статистику и состояние слотов с исходными значениями; под наблюдением исполните обычную тестовую запись через приложение. Убедитесь, что ошибка диска исчезла, архивирование продвигается и резервные копии годны. Если каталог продолжает расти, не пытайтесь ускорить очистку удалением файлов: сохраните графики и передайте их дежурному администратору.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Воспроизведение и проверка только в отдельной тестовой базе
SQL
Минимальная безопасная диагностическая команда для доступной тестовой или рабочей базы; возвращает настройки и количество слотов, не создаёт WAL намеренно.
SELECT current_setting('archive_mode') AS archive_mode, current_setting('max_wal_size') AS max_wal_size, (SELECT count(*) FROM pg_replication_slots) AS slots;#Как убедиться в исправлении и что делать дальше
Признаки успеха: PostgreSQL штатно принимает запись, файловая система имеет запас свободного места, новый WAL архивируется/получается репликой согласно конфигурации, а рост pg_wal контролируем. Если база не стартует даже после увеличения диска, оставьте файлы нетронутыми и передайте журнал старта, параметры размещения PGDATA, состояние резервных копий специалисту по аварийному восстановлению.