Como você alcança alta disponibilidade no PostgreSQL?

Question

Accepted Answer

**Alta disponibilidade (HA)** significa manter o banco de dados disponível mesmo quando falhas ocorrem — através de **replicação** (réplicas standby), **failover automático** (promovendo uma réplica quando a primária falha), e arquitetura apropriada. O objetivo: minimizar tempo de inatividade e perda de dados, já que indisponibilidades de banco de dados derrubam a aplicação inteira.

## A fundação: replicação + failover automático

```text
Primary ──(streaming replication)──▶ Standby replica(s)

If the PRIMARY fails:
  → a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
  → the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
```

A replicação mantém réplicas standby em sincronização; **failover automático** detecta falha na primária e promove uma réplica — transformando uma interrupção total em uma breve interrupção.

## Ferramentas de HA (automatizando failover)

```text
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
  Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
```

Failover manual é lento e propenso a erros, então ferramentas de HA (ou serviços gerenciados) o automatizam com segurança — incluindo prevenção de **split-brain** (duas primárias aceitando escritas, o que corrompe dados).

## Roteamento de conexões

```text
Applications need to find the CURRENT primary after a failover:
  → a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
    WRITES to the current primary and READS to replicas
  → after failover, routing updates to point to the new primary
```

## Considerações-chave de HA

```text
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
```

## Por que isso importa

Alta disponibilidade é conhecimento importante para operar sistemas PostgreSQL **críticos para produção**, porque indisponibilidades de banco de dados derrubam a aplicação inteira (o banco de dados é frequentemente a dependência mais crítica), então entender como manter Postgres disponível apesar de falhas é conhecimento valioso de nível sênior para sistemas confiáveis.

A fundação — **replicação mais failover automático** — é o que transforma uma falha de banco de dados primário (que de outra forma seria uma interrupção total da aplicação) em uma breve interrupção recuperável: réplicas standby permanecem sincronizadas, e quando a primária falha, uma réplica é automaticamente promovida para assumir.

Entender as **ferramentas de HA** (Patroni — a solução popular coordenando failover via um armazenamento de consenso; repmgr; ou Postgres em nuvem gerenciado com HA integrado) é importante porque automatizar failover com segurança é difícil de fazer manualmente.

Conhecer as **considerações-chave** é crítico: **replicação síncrona** para nenhuma perda de dados no failover, **múltiplas réplicas em zonas de disponibilidade** para sobreviver a falhas de zona, e especialmente **evitar split-brain** (prevenindo duas primárias de aceitar escritas simultaneamente, o que corrompe dados — um risco sério que consenso/fencing previne).

Entender **roteamento de conexões** (direcionando a aplicação para a primária atual após failover, via load balancers/proxies) e que failover (como backups) deve ser **testado** completa o conhecimento prático.

Saber que muitos times usam **Postgres gerenciado** para HA batida em combate também é relevante.

Já que a disponibilidade de banco de dados é crítica para sistemas em produção (uma interrupção derruba tudo), e já que alcançá-la requer entender replicação, failover automático, prevenção de split-brain, e roteamento de conexões (ou usar HA gerenciado), entender alta disponibilidade em PostgreSQL é conhecimento importante de nível sênior para arquitetar sistemas confiáveis e resilientes — uma preocupação frequentemente crítica para bancos de dados em produção e um tópico demonstrando entendimento de como construir infraestrutura de banco de dados que sobrevive a falhas, esperado para funções de banco de dados/infraestrutura sênior.