Добрый день! WAL по размеру больший чем сама база -

это нормально? Ну скажем: размер базы 30 Гб а WAL - 150 Гб?

Есть нюансы, но в общем не особо страшно.

Может у вас slave отвалился? или много апдейтов?

Но вообще — можэт быть симптомом, что что-то задержывает удаление WAL чрезмерно. (А можэт и не быть — вдруг у вас так транзакцыя задана, что по много раз переписывает одно место и загружает WAL).

Главное мониторить свободное место на диске

Кластера нет. Репликации тоже. На канале репликации только Barman работает

Если бы речь шла о MS-SQL ябы давно бежал шринкать базы.

(Из моих заметок) To check why WAL files aren't being removed: . Check restart_lsn for "in use" pg_replication_slots (see wal_status): SELECT slot_name, slot_type, wal_status, restart_lsn /*, ... */ FROM pg_replication_slots; . Check archiver-related information: SELECT * FROM pg_stat_archiver; NOTE. Given, for instance: . pg_walfile_name = 000000020000C6AE00000000 . last_archived_wal = 000000020000C6AD000000FF Naive hex-based difference will show us difference of 4294967041 WAL files. But this is simply a mistake. If you want to process these numbers using normal hex math, you have to remove 6 zeros that are there before last 2 characters. So, do to hex math, you first change "000000020000C6AE00000000" to "000000020000C6AE00" and "000000020000C6AD000000FF" to "000000020000C6ADFF", and then subtract them from each other. . Check wal_keep_size. . Check checkpoint-related information: SELECT * FROM pg_control_checkpoint();

Точно нет реплики? У меня был случай настроили реплику поигрались и удалили, а мастер об этом не знал и не удалял WALы покавесь диск не забил Это не обязательно ваш случай но я б проверил

Перепроверю, но мне кажется, что нет.

Ничего ненормального нет