Melhores Práticas de HA

Pratique failover trimestralmente; aplicativos devem tentar novamente erros transitórios. Estas regras mantêm clusters Patroni realmente disponíveis durante falhas reais.

Como Usar Esta Lista

• Aplique no design do cluster e após cada upgrade do Patroni/etcd.
• Use como um checklist de preparação para game-day.
• Compartilhe as seções de roteamento e retentativas com as equipes de aplicativos.
• Armazene o RTO medido a partir de drills ao lado de cada item onde for relevante.

A - Arquitetura

• Mínimo de três nós PostgreSQL para HA de produção. Um líder mais duas réplicas.
• Quórum etcd ou Consul de contagem ímpar (3 ou 5). Nunca DCS de dois nós.
• Separe o etcd dos hosts PostgreSQL quando possível. Reduz falhas correlacionadas.
• Habilite o watchdog Linux do Patroni (mode: automatic). Reduz a janela de split-brain.
• Defina maximum_lag_on_failover a partir do SLA de lag em bytes medido. Bloqueia promoção de dados obsoletos.

B - Roteamento e Pooling

• Aplicativos se conectam via hostname de escrita estável através de HAProxy + PgBouncer. Nenhum IP primário na configuração.
• HAProxy faz health check do REST /primary do Patroni, não apenas TCP 5432. Evita roteamento incorreto para réplicas.
• Execute RECONNECT ou recarregue o PgBouncer no callback de failover do Patroni. Limpa backends obsoletos.
• Documente endpoints de leitura vs escrita separadamente. Read-your-writes precisa de rota primária.
• Mantenha server_lifetime baixo o suficiente para failover (300s ou menos). Limite de conexão obsoleta.

C - Aplicativos

• Tente novamente erros de conexão transitórios com backoff exponencial. Durante a janela de failover.
• Defina connect_timeout nas strings de conexão. Falhe rapidamente, tente novamente mais cedo.
• Use chaves de idempotência para escritas durante janelas de retentativa. Evita efeitos colaterais duplicados.
• Alerta sobre a taxa de erro do DB do aplicativo durante a mudança de líder. O DB pode estar ativo enquanto os aplicativos não estiverem.
• Teste de carga com caminho de proxy, não conexões diretas a nós. Corresponde ao comportamento de produção.

D - Operações

• Drill de failover não planejado trimestral em staging; anual em produção com aprovação. Registre o RTO.
• Execute patronictl switchover antes de aplicar patches do SO no primário. Migração planejada do líder.
• Nunca use pg_ctl promote fora do Patroni. Evita dessincronização do estado do DCS.
• patronictl pause com tempo limitado; documente o proprietário. Retome o failover automático prontamente.
• Página em caso de mudança de função de líder do Patroni e perda de quórum do etcd. Failover automatizado ainda precisa de conscientização humana.

E - Alinhamento de Replicação

• Slot físico por réplica; monitore slots inativos. Segurança de disco WAL.
• No máximo um parceiro de sincronização, a menos que a latência seja modelada. Veja melhores práticas de replicação de streaming.
• Replicação e backups são complementares. HA não substitui pg_dump ou pgBackRest.
• Após upgrade principal, reconstrua o cluster Patroni em uma única versão principal. Sem membros mistos 17/18.

FAQs

Relacionados

• Noções Básicas de HA - Primer de RTO/RPO
• Patroni & etcd/Consul - configuração
• Proxies de Conexão - HAProxy e PgBouncer
• Testes de HA - runbook de game-day

Versões da Stack: 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+.