SessionProxy: HA-кластер Postgres
Архитектурная схема (archify) →
Три компонента, три разные роли
Кластер состоит из двух инстансов Postgres под управлением Patroni (один в роли primary, второй — standby, реплицирующий данные с primary), координационного хранилища etcd и балансировщика HAProxy перед обоими узлами.
Patroni-узлы физически хранят и обслуживают данные — это обычный Postgres, просто с надстройкой, которая умеет договариваться о том, кто сейчас главный.
etcd не хранит ни строчки бизнес-данных проекта — только состояние самого кластера: кто сейчас лидер. Через записи в etcd Patroni на разных узлах согласованно решает, кому быть primary, без риска, что оба узла одновременно посчитают себя лидером (split-brain).
HAProxy — единственная точка входа для приложения: слушает один порт и каждые несколько секунд опрашивает служебный эндпоинт :8008/primary на обоих Patroni-узлах, отправляя реальный трафик только на тот, который в данный момент отвечает 200 (то есть является primary). Приложению не нужно самому знать, какой из двух узлов сейчас главный.
Failover проверен вживую, не только описан
При остановке текущего primary через приблизительно 15 секунд standby-узел становится новым primary — Patroni на нём замечает, что лидер пропал (по истечении таймаута в etcd), и сам себя повышает. HAProxy при следующем опросе :8008/primary видит 200 уже у бывшего standby и переключает трафик туда без ручного вмешательства.
Это не теоретическое описание протокола, а протестированный сценарий с конкретной проверочной командой: SELECT pg_is_in_recovery(); возвращает f (false — «не реплика», то есть текущий primary) через HAProxy сразу после переключения. Умение назвать конкретную команду проверки, а не просто сказать «мы настроили HA», — то, что отличает реальный опыт от пересказа документации на собеседовании.
Почему это вообще нужно в тестовом/пет-проекте
Один узел Postgres — единая точка отказа: его падение останавливает весь сервис до ручного восстановления. Для системы, которая в теории могла бы обслуживать реальных пользователей (а не только демонстрировать код), HA-кластер — не излишество ради галочки в резюме, а прямое следствие требования «сервис должен продолжать работать при падении одной машины», которое стоит уметь сформулировать именно так, а не как «сделал, потому что было интересно».