Реализован проект по разделению нагруженного кластера PostgreSQL

В команду DevOps EFSOL обратился клиент с проблемой разваливающегося продакшн-кластера PostgreSQL, который также находился под постоянно высокой нагрузкой. Проблема стала системной и повторялась периодически.

Задачи клиента

Перед DevOps-инженерами EFSOL были поставлены следующие задачи:

• Диагностировать проблему разваливающегося кластера PostgreSQL и устранить ее.
• Решить вопрос с распределением нагрузки на кластер PostgreSQL.

Как мы решили задачи клиента

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

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

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

• Увеличено количество нод в кластере PostgreSQL (Patroni), создан второй кластер ETCD для нового кластера PostgreSQL (Patroni).
• Разделены ноды в кластере PostgreSQL (Patroni) на два независимых кластера.
• Новый кластрый PostgreSQL (Patroni) переведен на работу с новым кластером ETCD.
• Установлен HAproxy как точка входа приложения в кластер PostgreSQL (Patroni) для минимизации ошибок приложения при переключении кластера.
• Установлен PGBouncer, чтобы снять нагрузку с PostgreSQL по управлению жизненным циклом соединений.