🧠 Cluster Postgres com Patroni, Keepalived e HAProxy — Quando e Por Que Usar Cada Um?

Uma dúvida clássica que surge com frequência ao projetar um cluster PostgreSQL com high availability é:

“Se o Keepalived já oferece failover de IP via VRRP e posso checar o status do Patroni via REST API, por que eu ainda precisaria de HAProxy?”

Essa pergunta foi feita por um aluno do curso, que está montando um cluster PostgreSQL baseado em Patroni com 3 nós e quer entender se faz sentido adicionar HAProxy, ou se um Keepalived com checagens via API + TCP já seria suficiente para HA num ambiente pequeno.

---

📌 Pergunta do Aluno

“Eu entendo que o Keepalived faz failover no nível de IP (via VRRP) e que o check do Patroni é usado no script de saúde. Se tudo o que eu preciso é garantir failover para o leader do Patroni para conectividade de read/write, por que eu não posso simplesmente usar um VIP com Keepalived direcionado para a porta padrão do PostgreSQL sem HAProxy?”

---

🧩 Resposta — Explicada em Detalhes

De fato, com um cluster simples (3 nós, Patroni gerenciando failover, checks REST + TCP implementados no Keepalived) você pode construir um ambiente altamente disponível que funcione bem — especialmente para workloads menores ou aplicações não críticas como Zabbix. Isso funciona porque:

• O Keepalived pode mover um VIP para o nó atual do líder com base em checagens REST/TCP customizadas;
• O cliente conecta-se sempre ao mesmo IP/porta;
• E em muitos casos isso já é suficiente para garantir disponibilidade básica.

Esse modelo é funcional e mais simples do que arquiteturas tradicionais com load balancers dedicados.

---

⚠️ Por Que A Arquitetura de Produção Usa HAProxy?

No entanto, quando estamos falando de ambientes de produção ou aplicações realmente críticas, recomendamos incluir HAProxy (geralmente em front-ends dedicados, com Keepalived fornecendo um VIP para ele) — por vários motivos:

✅ 1. Separação de Responsabilidades

Keepalived só lida com IP failover, ou seja: ✔ Movimenta o VIP conforme prioridades de saúde ❌ Não entende a lógica de PostgreSQL (leader/replica) ❌ Não faz roteamento baseado no estado real do banco

HAProxy, por outro lado, fala com a API do Patroni e sabe qual nó é primário. Dessa forma, apenas o leader recebe tráfego de escrita, e não há chance de direcionar clientes erroneamente para um nó que já foi promovido para standby.

---

✅ 2. Failover Mais Limpo e Seguro

HAProxy:

• Pode detectar alterações imediatas de líderes
• Evita o envio de tráfego para um nó que está em transição
• Reduz janelas de erro (“read-only transaction”) durante failover — algo que scripts simples de Keepalived não conseguem gerenciar tão bem

---

✅ 3. Escalabilidade e Futuro

Ao adicionar HAProxy você abre portas para:

• Read/Write split
• Pooling eficiente
• Capacidade de distribuir conexões em múltiplos back-ends
• Fácil adição de PgBouncer ou outras camadas mais avançadas

Sem HAProxy, seu VIP aponta diretamente para PostgreSQL — e não há nenhuma camada intermediária de lógica de roteamento.

---

⚠️ 4. Proteção Contra Falha do Proxy

Se você usar apenas um Keepalived apontando diretamente para PostgreSQL, um problema no próprio proxy (ou no serviço que implementa a lógica de checagem) pode deixar todo o cluster inacessível.

Arquiteturas profissionais normalmente usam:

[ Aplicação ]
     ↓
VIP (Keepalived)
     ↓
HAProxy (2 instâncias)
     ↓
Patroni/PostgreSQL Cluster

Assim o Keepalived garante HA do HAProxy, e o HAProxy garante roteamento correto dentro do cluster.

---

🤝 Resumo — Quando Usar o Quê:

SituaçãoKeepalived sóKeepalived + HAProxyPequenos clusters, baixo tráfego✔✔ (opcional)Aplicações não críticas✔✔Produção com SLAs altos⚠✔ recomendadoNecessidade de escalabilidade ou read/write split❌✔

---

📌 Conclusão

Sim — para um cluster simples de 3 nós com Patroni e verificações personalizadas, um Keepalived bem configurado pode atender às necessidades básicas de alta disponibilidade.

Mas quando falamos de ambientes de produção, com expectativas de tolerância a falhas, failovers suaves, menor impacto em clientes e capacidade de escalar ou evoluir a arquitetura, utilizar HAProxy em conjunto com Keepalived ainda é o padrão recomendado pela maioria das referências de alta disponibilidade PostgreSQL.

Quer Aprender POSTGRES e a configurar o Cluster com o Patroni com super desconto?

https://www.udemy.com/course/postgrescompleto/?couponCode=C7F64792DCDCB1198550

https://www.udemy.com/course/clusterpostgres/?couponCode=FE2B9876CC7D99009125

🚀 Ready to boost your career in data?

👉 DBAcademy – DBA & Data Analyst Training
Over 1,300 lessons and 412 hours of exclusive content.
Includes subtitles in English, Spanish, and French.

🔗 https://filiado.wixsite.com/dbacademy

💡 Start learning today and become a highly in-demand data professional.