Три задачи discovery при работе с PostgreSQL master/replica — и как их решить

[ky0]

Сложновато.

Для случая с одной репликой можно обойтись обычными vIP, мигрирующими между хостами с помощью keepalived.

[krylosov-aa]

VIP с keepalived рабочий вариант для 1 задачи, если инфраструктура позволяет (bare-metal или VM с L2-доступом, root на хостах). Но он не решает задачи 2 и 3. Хотя понимаю, что в простых случаях их и не требуется решать.

[gsl23]

Он требует внешнего DCS (etcd, Consul или ZooKeeper). Если Patroni уже есть — пользуйтесь его API. Если нет — разворачивать весь стек ради discovery избыточно.

DCS это прежде всего защита от сплитбрейн. Так что тут есть смысл и разворачивать его совсем не избыточно, дело не только в autodiscovery.

[Sleuthhound]

Утилита интересная, только кажеться, что писать такое на Си в 26 году это оверкил, но снимаю шляпу)

Как можно использовать pg-status в связке с haproxy? Есть ли готовые сценарии?

Кстате для автоматической генерации конфига haproxy если используется patroni вполне удобно использовать confd, который ходит в etcd/consul за топологией и обновляет haproxy.conf на основе шаблона.

[krylosov-aa]

Спасибо) На C писал потому что очень люблю этот язык, ну и хотелось чтобы был очень лёгким и быстрым.

HAProxy по идее можно интегрировать с pg-status, чтобы он предоставлял информацию для того куда проксить запрос. Но готового конфига у меня нет)