Найти в Дзене
VarNote

Столкнулся с проблемой: оператор PostgreSQL для Kubernetes CloudNativePG, с плагином бэкапов Barman Cloud генерирует десятки тысяч GET и

LIST запросов к S3 хранилищу. Причина — сайдкар контейнер постоянно проверяет WAL архивы для управления политикой хранения. Что не помогло: - Отключение бекапов WAL — диск 100Гб забился за 2 дня (внезапно это базовая фича плагина, WAL журналы все равно создавались) - Оптимизация размера и периода отправки WAL в S3 - Переход на плагин WAL-G от Yandex с инкрементальными копиями Что помогло: Одна строка в конфиге, которая увеличивает интервал проверки retention политики с нескольких минут до 6 часов: spec: instanceSidecarConfiguration: retentionPolicyIntervalSeconds: 21600 Результат: GET и LIST запросы сократились на ~95%, функциональность не пострадала. Вывод: читайте внимательнее документацию 🫠 Подробнее в блоге: https://varnote.ru/cloud/cloudnative-pg-fix-barman varnote | #varnote #kubernetes #cloudnativepg #barman #devops

Столкнулся с проблемой: оператор PostgreSQL для Kubernetes CloudNativePG, с плагином бэкапов Barman Cloud генерирует десятки тысяч GET и LIST запросов к S3 хранилищу. Причина — сайдкар контейнер постоянно проверяет WAL архивы для управления политикой хранения.

Что не помогло:

- Отключение бекапов WAL — диск 100Гб забился за 2 дня (внезапно это базовая фича плагина, WAL журналы все равно создавались)

- Оптимизация размера и периода отправки WAL в S3

- Переход на плагин WAL-G от Yandex с инкрементальными копиями

Что помогло:

Одна строка в конфиге, которая увеличивает интервал проверки retention политики с нескольких минут до 6 часов:

spec:

instanceSidecarConfiguration:

retentionPolicyIntervalSeconds: 21600

Результат: GET и LIST запросы сократились на ~95%, функциональность не пострадала.

Вывод: читайте внимательнее документацию 🫠

Подробнее в блоге: https://varnote.ru/cloud/cloudnative-pg-fix-barman

varnote | #varnote #kubernetes #cloudnativepg #barman #devops