собирает по нему статситику.
И при осмотре выявилось что на некоторых бд stats_reset не выполнялось автоматически аж с мая месяца.
+ я вижу какое то запредельное кол-во failed_count 6500. Хотя в логах нет ошибок с архивацией или archive_command.
Сделал сброс статистики руками, ща все ок. Но таких баз с два десятка. Версия 12.
Архив логи складываются в директорию, откуда их забирает система резервного копирования раз в час.
1.Куда копать почему есть failed_count большой.
2. Почему не сбрасывается статистика и можно ли сделать, что бы чаще щелкал stats_reset. кроме как в кроне руками прописывать? (баз много более 250 с стендбаями.)
1.Куда копать почему есть failed_count большой. Посмотрите в last_failed_time, там таймстемп когда была последняя ошибка архивирвоания, далее поднимайте логи за это время и смотрите. 2. Почему не сбрасывается статистика Статистика архивера является общей для всего экземпляра СУБД, сбрасывать ее надо через pg_stat_reset_shared('archiver'). и можно ли сделать, что бы чаще щелкал stats_reset. кроме как в кроне руками прописывать? (баз много более 250 с стендбаями.) имхо сбрасывать не обязательно, там же накопительная статистика, следовательно в проме у вас будут counter, по которым вы будете строить rate. Ну а если очень хочется сбрасывать, то по крону, "автосброса" статистики нет
Обсуждают сегодня