DevOps-инженеры EFSOL произвели разбор и установили следующее: в момент прерывания работы в сетевой подсистеме ВМ, происходило переключение PostgreSQL с мастера на реплику, а Patroni не мог самостоятельно восстановить целостность кластера, ссылаясь на неполный файл транзакций. Происходило это вследствие недостаточного количества WAL-файлов — реплика не успевала получить необходимые разностные транзакции.
Требовалось внести изменения в конфигурационный файл postgresql.conf, используемый Patroni, кратно увеличив параметр wal_keep_size. В процессе работ выяснилось, что используемый кластер ETCD был в неисправном состоянии, он был исправлен.
Для решение проблемы распределения нагрузки на PostgreSQL, было принято решение разделить кластер PostgreSQL на два. Это было обусловлено спецификой данных, т.к. большую часть нагрузки генерировал один пользователь (условно), у которого были отдельные данные.
В результате проекта, работа кластера PostgreSQL стабилизирована. По данным мониторинга аномалий после изменения конфигурации не обнаружено. Нагрузка кластера PostgreSQL распределена - нагруженный кластер PostgreSQL разделен на два разных кластера.
Контактная информация:
+7 495 230 03 03
efsol@efsol.ru
EFSOL DevOps реализовали проект по стабилизации нагруженного кластера PostgreSQL
21.06.2023
В DevOps-команду EFSOL обратился клиент с проблемой разваливающегося продакшн-кластера PostgreSQL сервиса генерации онлайн-отчетов, который находился под постоянной высокой нагрузкой. По итогу выполнения проекта, клиент получил стабильную работу PostgreSQL с распределением нагрузки на второй кластер.