| f - неатктивен, проверьте куда он должен отправлять и должен ли? Удалить его надо и через некоторое время все лишние wal сами удалятся. Эта база slave?
Нет, это кластер main. postgres@singularity:~$ pg_lsclusters Ver Cluster Port Status Owner Data directory Log file 14 beta 5433 online,recovery postgres /var/lib/postgresql/14/beta /var/log/postgresql/postgresql-14-beta.log 14 main 5432 online postgres /var/lib/postgresql/14/main /var/log/postgresql/postgresql-14-main.log 14 standby1 5433 down postgres /var/lib/postgresql/14/standby1 /var/log/postgresql/postgresql-14-standby1.log Это стенд. Никакие транзакции не идут, только Zabbix что-то творит в БД.
Если это тестовый стенд, то можно удалить неактивный слот SELECT pg_drop_replication_slot('replica');
Пока не понимаю, зачем нарушать правило "работает - не трогай". Место на диске VPS пусть кушает, пока не разберусь. Это баг или фича PostgreSQL? Ну ок, попробую. postgres=# SELECT pg_drop_replication_slot('replica') \gx -[ RECORD 1 ]------------+- pg_drop_replication_slot |
Место кончится и перестанет работать. Это фича, пока слот есть, логи удерживаются, т.к. возможно это временная недоступность, когда появится - тогда логи передадутся и на этом сервере удалятся. Но если не появится, то база встанет, т.к. логи писать некуда будет
точку с запятой похоже пропустил, не удалился слот
max_slot_wal_keep_size - есть предохранитель
postgres=# SELECT pg_drop_replication_slot('replica'); ERROR: replication slot "replica" does not exist Как теперь восстановить репликацию?
ок. Логи начали удаляться по-тихоньку?
Вроде бы ничего не изменилось в сторону уменьшения. Наоборот, объём увеличился. postgres@singularity:~$ du -s -BM /var/lib/postgresql/archive 3905M /var/lib/postgresql/archive
Обсуждают сегодня