К нам в EFSOL обратился клиент с проблемой разваливающегося продакшн-кластера PostgreSQL, который также находился под постоянно высокой нагрузкой (предельной для используемых ресурсов). Проблема стала системной и повторялась периодически. Развал кластера решался реинитом отвалившейся ноды, но это было только временное решение до следующего сбоя.
DevOps-специалисты EFSOL произвели разбор и установили следующее:
В момент прерывания работы в сетевой подсистеме ВМ (привет, Hetzner), происходило переключение PostgreSQL с мастера на реплику, а Patroni не мог самостоятельно восстановить целостность кластера, ссылаясь на неполный файл транзакций. Таким образом, мастер "отваливался". Происходило это вследствие недостаточного количества WAL-файлов — реплика не успевала получить необходимые разностные транзакции.
Решение проблемы разваливающегося кластера PosgtreSQL
Требовалось внести изменения в конфигурационный файл postgresql.conf, используемый Patroni, кратно увеличив параметр wal_keep_size. Данный параметр отвечает за суммарный размер хранимых файлов транзакций при обычной работе сервера. В процессе работ выяснилось, что используемый кластер ETCD был в неисправном состоянии, т.к. на двух из трех нод, были переполнены базы данных и состояние\изменения в состоянии кластера не фиксировалось. Кластер ETCD был исправлен.
В итоге: работа кластера PostgreSQL стабилизировалась, но он по-прежнему находился под высокой нагрузкой.
Решение проблемы распределения нагрузки на PostgreSQL
Поэтому было принято решение разделить кластер PostgreSQL на два, что позволяла сделать специфика данных в БД, которые можно разнести по двум кластерам, т.к. данные используются независимыми потребителями сервиса.
Реализация
- Увеличено количество нод в кластере PostgreSQL (Patroni), создан второй кластер ETCD для нового кластера PostgreSQL (Patroni).
- Разделены ноды в кластере PostgreSQL (Patroni) на два независимых кластера.
- Новый кластрый PostgreSQL (Patroni) переведен на работу с новым кластером ETCD.
- Установлен HAproxy как точка входа приложения в кластер PostgreSQL (Patroni) для минимизации ошибок приложения при переключении кластера.
- Для управления подключениями установлен PGBouncer, чтобы снять нагрузку с PostgreSQL по управлению жизненным циклом соединений.
В итоге: нагруженный кластер PostgreSQL разделен на два, его работа стабилизировалась, а нагрузка распределена.
Решаем ваши задачи по построению и обслуживанию CI/CD и продакшн-инфраструктуры — запрос можно оставить здесь.