Consultoria PostgreSQL Alta Disponibilidade — Arquitetura 24/7 com Streaming Replication, Patroni e Failover Testado.

Alta disponibilidade PostgreSQL não é um parâmetro que se liga — é uma arquitetura que se desenha, testa e sustenta. A diferença entre um cluster que "tem replicação" e um cluster que sustenta SLA contratual de 99,99% em produção está em uma dezena de decisões técnicas concretas: quórum de DCS, timeout de failover, roteamento de conexão, política de fencing, ordem de start após restore. Este guia é a base da metodologia de consultoria PostgreSQL que aplicamos em ambientes multi-AZ críticos.

A HTI opera bancos de dados de missão crítica desde 1990 e aplica ao PostgreSQL o mesmo padrão operacional que sustenta 99,9999% em ambientes Oracle, MySQL e SQL Server. HA aqui não é discurso — é runbook numerado, DR testado por trimestre e RTO medido em minutos.

Postgres não vem com HA "de fábrica" no mesmo sentido que Oracle RAC ou SQL Server Always On. Existe replicação nativa (Streaming Replication e Logical Replication), mas failover automático, detecção de falha, promoção segura e roteamento de conexão são responsabilidades da stack ao redor — Patroni + DCS + pooler + monitoramento. Isso é bom (flexibilidade e portabilidade máxima) e ruim (é fácil errar em qualquer uma das camadas).

O padrão que vemos com mais frequência em Health Check: uma réplica de leitura configurada como "plano de HA", sem orquestrador, sem quórum, sem teste de promoção. Quando o primário cai de madrugada, alguém acorda para promover manualmente, e o RTO real chega em horas. HA funcional exige que a promoção aconteça sem intervenção humana, no meio da madrugada, dentro do tempo previsto — e que o time confie o suficiente na automação para deixar acontecer.

Antes de escolher tecnologia, defina três números com o negócio, por escrito. SLA (Service Level Agreement): percentual de uptime contratual — 99,9% permite 8h45min de indisponibilidade por ano, 99,99% permite 52 min, 99,999% permite 5 min. RTO (Recovery Time Objective): quanto tempo o negócio aceita ficar fora após uma falha — 5 min, 30 min, 4 horas. RPO (Recovery Point Objective): quantos dados o negócio aceita perder — zero, 1 s, 5 min, 1 h.

Esses três números determinam praticamente toda a arquitetura. RPO zero exige replicação síncrona. RTO abaixo de 1 minuto exige failover automático com DCS e conexões roteadas por VIP/pooler. SLA 99,999% exige múltiplas AZs, DR geográfico e observabilidade com alerta acionável — não painel visual. Sem esses números fixados, qualquer discussão de arquitetura vira preferência técnica.

"HA sem SLA definido é decoração. HA sem RTO/RPO testados é aposta."

Streaming Replication é replicação física: o primário envia continuamente o WAL para uma ou mais réplicas (standbys), que aplicam o WAL em modo hot standby — disponíveis para leitura. É a base de qualquer arquitetura HA em Postgres. Modo assíncrono é o default; síncrono exige configuração explícita e tem custo em latência de commit.

Replication slots vs wal_keep_size

Use replication slots em produção — garantem que o primário retém o WAL necessário para cada réplica, mesmo que ela fique offline por horas. O risco: se uma réplica desaparecer permanentemente e o slot não for removido, o WAL cresce até encher o disco do primário. Monitore pg_replication_slots e tenha alerta para pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) acima de um threshold (por exemplo 5 GB).

Thresholds práticos em produção OLTP: replay_lag < 500ms em condição normal, alerta em > 5s, incidente crítico em > 30s. Lag alto por horas geralmente indica réplica com hardware inferior, I/O saturado ou query longa segurando snapshot na réplica (hot_standby_feedback mal calibrado).

Patroni é o orquestrador de cluster PostgreSQL de facto em 2026 — usado pela Zalando (que o criou), CloudNativePG, Crunchy Data e praticamente todo operador Kubernetes de Postgres. Ele resolve o que Streaming Replication não faz: detecção de falha do primário, eleição de líder via DCS (Distributed Configuration Store — etcd, Consul, ZooKeeper), promoção segura, fencing do primário antigo para evitar split-brain, e REST API para automação.

DCS com quórum — o detalhe que define split-brain

DCS precisa ter quórum: 3 nós (tolera 1 falha), 5 nós (tolera 2), sempre número ímpar. Rodar etcd em 2 nós não é HA — é menos resistente do que rodar em 1 nó, porque a perda de qualquer um trava todo o cluster. Distribua os nós de DCS por AZs diferentes. Nunca coloque etcd e Postgres no mesmo host físico em produção — falha correlata elimina os dois de uma vez.

Parâmetros críticos de failover

ttl (default 30s): tempo até o líder ser considerado morto se não renovar o lease. Reduzir para 15s acelera failover mas aumenta risco de false-positive em rede instável. loop_wait (10s): frequência do health check. maximum_lag_on_failover: bytes máximos de lag que uma réplica pode ter para ser promovida — em síncrona, zero; em assíncrona, alinhe com o RPO acordado. synchronous_mode_strict = false permite que o cluster continue aceitando writes se todas as síncronas caírem (com perda de garantia de RPO); true prefere indisponibilidade a perda — decisão de negócio, não técnica.

Failover no Postgres promove uma réplica — mas a aplicação continua apontando para o IP do primário antigo, agora inalcançável. Você precisa de uma camada que redirecione conexão para o líder atual, sem alterar string de conexão da aplicação. Três padrões funcionam:

• VIP flutuante (keepalived, Corosync): IP virtual que "salta" para o novo líder após failover. Simples, funciona em rede plana; ruim em multi-AZ ou cloud sem IPs flutuantes livres.
• HAProxy + Patroni REST API: HAProxy consulta o endpoint /master ou /replica de cada nó Patroni via health check HTTP; roteia writes para o líder atual, reads para qualquer réplica. Padrão de mercado em bare-metal e VMs.
• PgBouncer com reload orquestrado: PgBouncer aponta para o líder; após failover, Patroni dispara callback que atualiza pgbouncer.ini e faz reload. Combina pool + roteamento; recomendado para workload com alta concorrência.

Em Kubernetes, o padrão é service gerenciado pelo operador (Zalando postgres-operator, CloudNativePG): dois services por cluster — -rw aponta para o líder atual, -ro para réplicas. O operador atualiza os endpoints do service em segundos após failover.

Replicação replica erros humanos em milissegundos. DROP TABLE no primário chega na réplica sem cerimônia. HA cobre falha de infraestrutura — não cobre falha operacional, corrupção lógica, ransomware ou "alguém rodou o script errado". Backup + PITR é camada separada e não-negociável.

A ferramenta de referência para PostgreSQL em produção é pgBackRest — backup full/differential/incremental, retenção configurável, verificação de integridade, restore paralelo, WAL archiving assíncrono com compressão. Barman é alternativa válida com integração mais direta em ambientes Debian/Ubuntu. pg_dump tem lugar apenas em dumps lógicos pontuais — não é solução de backup em produção.

Regra 3-2-1 sem exceção: 3 cópias dos dados, em 2 mídias diferentes, sendo 1 em localização geográfica separada. Armazene backups fora da mesma conta/tenant de cloud da produção (segregação de blast radius em incidente de credencial). Teste restore em ambiente isolado nos últimos 90 dias — se você não sabe o tempo de restore, você não sabe seu RTO real.

Failover que nunca foi disparado em produção não é HA — é esperança. A HTI mantém rotina trimestral de chaos drill para os clientes em DBA Remoto PostgreSQL: derrubada controlada do primário, medição de RTO real, validação de que a aplicação reconectou, verificação de integridade dos dados e revisão do runbook a cada exercício.

O runbook mínimo de failover

• Detecção: quais alertas disparam e para quem — Patroni via REST API + Prometheus pg_up == 0 + monitoramento externo de porta.
• Confirmação: critério objetivo para não agir em falso-positivo (rede vs banco); Patroni já faz isso, humano só valida.
• Promoção: automática via Patroni; manual documentada como fallback (patronictl failover).
• Reconexão da aplicação: validação em segundos, não em promessa. Métrica: taxa de erro por endpoint pós-failover.
• Fencing do primário antigo: Patroni cuida com pg_rewind; validar que o nó voltou como réplica, não como split-brain.
• Post-mortem: RTO real, RPO real (via análise de WAL), gaps identificados, ação corretiva com prazo.

Chaos drill é rotina: derrubar o primário no horário combinado, medir. Um cluster que não foi testado em 90 dias tem alta probabilidade de falhar quando precisar — configuração drifta, DNS quebra, certificado vence, backup deixa de rodar em silêncio.

Arquitetura HA sem observabilidade acionável entrega SLA no papel — não na operação. O mínimo em produção:

• postgres_exporter ou pgwatch2 exportando métricas para Prometheus.
• Dashboards em Grafana com paineis de: lag de replicação, taxa de commit, hit ratio, autovacuum, WAL generation rate, tempo de checkpoint, top queries por pg_stat_statements.
• Alertas acionáveis — não "CPU alta", mas "lag de replicação > 5s por 2 min", "datfrozenxid age > 1B", "checkpoint por WAL > 30% dos últimos 100", "pg_is_in_recovery() mudou de estado".
• Roteamento de alerta 24/7 com escalonamento (PagerDuty, Opsgenie, plantão interno) — alerta que ninguém atende é ruído.
• Runbook por classe de incidente, versionado, revisado a cada drill.
• Monitoramento comportamental que vai além de métricas de infra — em ambientes gerenciados pela HTI, isso é feito com DBSnoop (ferramenta proprietária) que rastreia padrões de ingestão, tentativas de acesso a objetos protegidos e desvios comportamentais aplicáveis a qualquer RDBMS do portfólio.

• DCS sem quórum (2 nós de etcd): qualquer falha trava o cluster inteiro.
• Réplica no mesmo rack ou mesma AZ do primário: falha correlata elimina os dois; HA que não sobrevive à queda de uma AZ não é HA.
• Synchronous_mode_strict = true sem múltiplas réplicas síncronas: qualquer manutenção derruba writes.
• Replication slot esquecido: réplica removida, slot ativo, WAL cresce até encher o disco do primário e derrubar o banco.
• hot_standby_feedback = on com query longa na réplica: bloqueia vacuum no primário e gera bloat descontrolado.
• Aplicação com pool sem retry/reconnect logic: failover funciona em 15 segundos, mas a aplicação leva 10 minutos para se recuperar porque HikariCP/pgpool está com connectionTimeout de 30 min.
• Backup nunca restaurado: descobre-se em incidente que o pgBackRest está com repo corrompido há 3 meses.
• Runbook em Wiki que ninguém leu: na hora do incidente, cada engenheiro toma uma decisão diferente.

Alta disponibilidade PostgreSQL é o tipo de projeto que raramente sai bem "na primeira tentativa" quando desenhado por quem opera Postgres pela primeira vez. Três cenários pedem consultoria especializada:

• Greenfield com SLA contratual: ambiente novo, com SLA acordado com cliente ou regulador. Desenhar errado no início custa 10x reprojetar depois — escopo típico de consultoria PostgreSQL.
• Cluster existente que nunca fez failover real: auditoria de HA, chaos drill guiado, correção do runbook, medição de RTO real — natural em um Health Check focado em disponibilidade.
• Operação 24/7 sem time dedicado: arquitetura HA sem gente de plantão que sabe o que fazer no incidente é meia-solução. Cobrimos com DBA Remoto PostgreSQL — NOC 24/7, SLA contratual, DBSnoop na operação.

A HTI opera bancos de dados relacionais desde 1990, sustenta ambientes com SLA de até 99,9999% em produção real (padrão HTI multi-RDBMS) e trabalha a partir de sala física de acesso restrito no PIT em São José dos Campos. Não vendemos hora de tentativa — vendemos arquitetura, runbook e chaos drill como padrão operacional.