Теперь, давайте поговорим, как можно обнаружить, что распух каталог pg_wal/.

По идее PostgreSQL всегда поддерживает его в оптимальном для себя состоянии на уровне определенных файлов конфигурации, и, как правило, он не должен расти выше определенных пределов.

Есть параметр max_wal_size, который определяет максимальное значение. Плюс есть параметр wal_keep_segments — дополнительное количество сегментов, которые мастер хранит для реплики, если вдруг реплика недоступна продолжительное время.

Посчитав сумму max_wal_size и wal_keep_segments, мы можем примерно оценить, сколько места будет занимать каталог pg_wal/. Если он быстро растет и занимает гораздо больше места, чем рассчитанное значение, это значит, что есть какая-то проблема, и нужно с этим что-то делать.

В операционной системе Linux есть команда du -csh. Мы можем просто в мониторинг загнать значение и смотреть, сколько у нас там журналов транзакций; держать посчитанную метку, сколько он должен и сколько он по факту занимает, и как-то реагировать на изменение цифр.

Другое место, где мы смотрим, это представления pg_replication_slots и pg_stat_archiver. Наиболее частыми причинами, почему pg_wal/ занимает много места являются забытые слоты репликации или сломанная архивация. Другие причины также имеют место быть, но на моей практике встречались очень редко.

И, конечно же, всегда бывают ошибки в логах PostgreSQL, связанные именно с архивной командой. Других причин, которые связаны с переполнением pg_wal/, там, к сожалению, не будет. Мы можем там отловить только ошибки архивации.