Устранение роста WAL в PostgreSQL начинается с проверки слотов репликации и архивирования, а не с срочного расширения диска. Журналы остаются на месте по причине, поэтому сначала нужно найти потребителя и подтвердить работоспособность восстановления.
В исходном кейсе платёжная система работала на PostgreSQL 12. WAL перестал освобождаться, том с бэкапами быстро рос, а Barman отклонял неподдерживаемый аргумент daemon. Репликация выглядела исправной. Проверка обнаружила оставшийся физический слот без потребителя.
Официальное описание представления pg_replication_slots в PostgreSQL 12 показывает роль restart_lsn: это самая старая позиция WAL, которая ещё может понадобиться потребителю. Документация Barman описывает receive-wal как отдельный процесс и связывает получение журналов со слотами и политикой удержания.
Заполненный диск является следствием
Дополнительное место даёт время, но не устраняет удержание WAL. Неактивный слот продолжает защищать старые сегменты, если PostgreSQL считает, что потребитель вернётся. Ошибка archive_command создаёт другую очередь. Настроенный приёмник тоже может давно не получать новые журналы.
Проверка начинается с pg_replication_slots и pg_stat_replication. Для каждого слота нужно определить тип, состояние, restart_lsn и ожидаемого потребителя. Затем это сопоставляют с реальными репликами и системой резервного копирования. Слот без подтверждённого владельца нельзя считать безопасным.
Перед изменениями сохраняют снимок состояния: размер каталогов, скорость роста, список слотов, активность архивации и положение приёмника. Эти данные нужны для сравнения после ремонта. Без исходной точки временное замедление роста легко принять за устранение причины.
Базовый список проверок из материала о состоянии базы данных полезно дополнить архивированием WAL. Наличие сервиса и свободного места ещё не подтверждает, что база может быть восстановлена до нужной точки.
Сначала восстанавливают путь архивирования
Удаление слота без проверки способно остановить реплику или лишить бэкап необходимых журналов. Безопасная последовательность начинается с карты потребителей. Затем проверяют активность, альтернативный путь восстановления и только после этого принимают решение о действительно потерянном слоте.
В кейсе установленная версия Barman не поддерживала используемый аргумент. Команда включила приём WAL поддерживаемым способом через системную конфигурацию, проверила путь archive_command и коды возврата, затем принудительно переключила WAL. Новый сегмент должен был пройти цепочку целиком.
Отдельно проверяют права доступа, свободное место на стороне архива и состояние сетевого соединения. Ошибка может находиться вне PostgreSQL. Поэтому тест должен подтверждать не только создание сегмента, но и его доставку, регистрацию в системе бэкапов и пригодность для восстановления.
Материал про резервные копии и восстановление подчёркивает тот же принцип. Бэкап считается рабочим после проверки восстановления, а не после появления очередного файла в каталоге.
После ремонта нужны постоянные ограничения
Параметры max_wal_size, wal_keep_size, archive_timeout и сжатие настраивают под реальную запись и доступный объём диска. Универсального значения нет. В мониторинг включают объём WAL, свежесть архива, отставание слотов, состояние приёмника и оставшееся время до заполнения файловой системы.
Практика аварийного восстановления серверов показывает ценность заранее написанного сценария. Для PostgreSQL он должен содержать диагностические запросы, список потребителей, владельца бэкапов, путь эскалации и условия изменения слота.
Сигнал тревоги должен учитывать не только процент заполнения. Полезнее оценивать скорость роста и оставшееся время до исчерпания места. Такой прогноз даёт оператору окно для проверки, согласования действий и безопасного переключения, а не вынуждает удалять файлы под давлением аварии.
После исправления выполняют контрольное восстановление или проверяют уже установленный сценарий. Архив без испытанного восстановления остаётся гипотезой. Команда должна знать, какие журналы требуются, кто запускает процедуру и как подтверждается целостность полученной базы.
Изменения документируют как операционное решение: что наблюдали, какую гипотезу проверили, какие команды выполнили, какие доказательства получили и как откатить действие. Эта запись ускоряет следующий инцидент и защищает от повторного создания заброшенного слота или неверной настройки приёмника.
Ответственный оператор также подтверждает закрытие тревоги только после стабильного наблюдения, а не сразу после освобождения места.
В исходном случае рост стабилизировали, архивирование восстановили, а систему сохранили без простоя. Повторяемый результат обеспечивает не разовая команда, а связка мониторинга, владельцев и проверяемого восстановления.
Частые вопросы
PostgreSQL сохраняет журналы, которые ещё могут понадобиться потребителю слота. Заброшенный потребитель способен удерживать старые сегменты и заполнять диск.
Нет. Сначала определяют потребителя, проверяют реплики и бэкапы, подтверждают ненужность слота и оценивают последствия для восстановления.
Проверяют приёмник, команды архивации и их результаты, выполняют контролируемое переключение WAL и подтверждают появление нового сегмента во всей цепочке.
Расширение диска лишь создаёт запас времени. Причину удержания в слоте, приёмнике или команде архивации всё равно нужно найти и устранить.
Если WAL растёт, а состояние репликации или архивов неочевидно, закажите технический аудит PostgreSQL и бэкапов до того, как свободное место превратится в таймер инцидента.
