Здесь может быть Ваша реклама

Подробнее
1708

Поделиться

DevOps-инженеры EFSOL произвели разбор и установили следующее: в момент прерывания работы в сетевой подсистеме ВМ, происходило переключение PostgreSQL с мастера на реплику, а Patroni не мог самостоятельно восстановить целостность кластера, ссылаясь на неполный файл транзакций. Происходило это вследствие недостаточного количества WAL-файлов — реплика не успевала получить необходимые разностные транзакции.

Требовалось внести изменения в конфигурационный файл postgresql.conf, используемый Patroni, кратно увеличив параметр wal_keep_size. В процессе работ выяснилось, что используемый кластер ETCD был в неисправном состоянии, он был исправлен.

Для решение проблемы распределения нагрузки на PostgreSQL, было принято решение разделить кластер PostgreSQL на два. Это было обусловлено спецификой данных, т.к. большую часть нагрузки генерировал один пользователь (условно), у которого были отдельные данные.

В результате проекта, работа кластера PostgreSQL стабилизирована. По данным мониторинга аномалий после изменения конфигурации не обнаружено. Нагрузка кластера PostgreSQL распределена - нагруженный кластер PostgreSQL разделен на два разных кластера.

Нужна помощь в решении IT-задач? Обращайтесь!

Интервью

Декоративное изображение

Андрей Герасимчук, ProSpace: «Спрос на решения для управления торговыми инвестициями будет расти»

Зачем «Смарт-Ком» сменила позиционирование на ProSpace, каких решений для сферы FMCG не хватает на отечественном ИТ-рынке и какие инновации наиболее перспективны?

Новость от компании:

Декоративное изображение
Retail.ru использует файлы cookie для хранения данных.
Продолжая использовать сайт, вы даёте согласие на работу с этими файлами