Noções Básicas de HA

Alta disponibilidade para PostgreSQL significa sobreviver à perda do primário com um tempo de recuperação definido (RTO) e uma janela de perda de dados aceitável (RPO). Os aplicativos devem se reconectar e tentar novamente durante a janela de failover.

Receita

Meta de OLTP Tier-0: 99,95% de tempo de atividade, RTO < 60s, RPO < 30s com standby físico assíncrono + Patroni 3.x.

-- Verifica se o standby está pronto para promoção
SELECT pg_is_in_recovery(), pg_last_wal_replay_lsn(), now() - pg_last_xact_replay_timestamp() AS replay_delay;

# String de conexão do aplicativo: direciona para o primário via proxy, não IP de nó bruto
# postgresql://app:***@pg-primary.internal:5432/appdb?connect_timeout=5&application_name=checkout

Quando usar isso: Qualquer banco de dados de produção onde minutos de interrupção de gravação afetam diretamente a receita ou os créditos de SLA.

Exemplo de Trabalho

Defina SLOs, meça o orçamento de failover, configure a retentativa do cliente:

-- No standby: frescor da replicação antes do teste
SELECT CASE
  WHEN pg_last_xact_replay_timestamp() IS NULL THEN 'sem replicação ainda'
  ELSE (now() - pg_last_xact_replay_timestamp())::text
END AS replay_age;

# Patroni 3.x: verifica o líder do cluster (do host de operações)
curl -s http://patroni-node1:8008/cluster | jq '.members[] | {name, role, state}'

# Padrão de retentativa de aplicativo (psycopg) - simplificado
import time
import psycopg
 
for attempt in range(5):
    try:
        with psycopg.connect(conninfo, connect_timeout=5) as conn:
            conn.execute("SELECT 1")
            break
    except psycopg.OperationalError:
        time.sleep(2 ** attempt)

O que isso demonstra:

• HA é uma propriedade do sistema: PostgreSQL + standby + orquestração + proxy + retentativas do aplicativo.
• O atraso de replicação no standby limita o RPO assíncrono antes da promoção.
• Os clientes devem usar timeouts e backoff exponencial durante a troca de DNS/proxy.

Mergulho Profundo

Métricas Principais

Camadas da Pilha de HA

Matemática de Tempo de Atividade

99,9% permite ~43 minutos de inatividade por mês. 99,95% permite ~22 minutos. Os testes de failover devem provar que você permanece dentro do orçamento, incluindo o tempo de inicialização a frio do aplicativo.

Armadilhas

• IP primário codificado em aplicativos - O failover é bem-sucedido, mas os aplicativos permanecem inativos. Correção: Nome do host do proxy ou descoberta de serviço.
• Sem retentativa do aplicativo em 57P01 / redefinição de conexão - Um breve lapso se torna uma interrupção visível para o usuário. Correção: Retentar erros transitórios para leituras idempotentes e gravações seguras.
• PgBouncer sem tempo de vida do servidor - Conexões obsoletas com o primário morto. Correção: server_lifetime + verificações de integridade; pausar/retomar durante o failover.
• Standby muito atrasado - Promover com RPO grande. Correção: Alertas de atraso de byte antes de declarar HA pronto.
• HA sem documentação de operações testada - Tempo de atividade apenas teórico. Correção: Jogo de guerra de failover Patroni trimestral.

Alternativas

FAQs

Relacionados

• Patroni & etcd/Consul - failover automatizado
• Proxies de Conexão - roteamento durante o failover
• Testes de HA - testes de jogo de guerra
• Noções Básicas de DR - níveis de RPO/RTO

Versões da pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.