Failover inseguro no PostgreSQL no Kubernetes: lição prática de alta disponibilidade da Datadog

A Datadog não descobriu um bug no Patroni ou no PostgreSQL, descobriu uma contradição estrutural entre o modelo de alta disponibilidade esperado e a realidade operacional em Kubernetes. O problema não estava na ferramenta, mas na configuração: replicação assíncrona + maximum_lag_on_failover rígido + rede instável = failover bloqueado por segurança. Isso expôs uma armadilha comum em ambientes de nuvem: assumir que 'zona de falha' é só um data center físico, quando na verdade pode ser uma partição de rede entre pods no mesmo cluster, causada por políticas de CNI, limites de QoS ou até por uma atualização de kernel no nó.

O ajuste para synchronous_commit = remote_apply não é só sobre durabilidade, é uma mudança de contrato operacional. Agora, cada escrita depende da aplicação física do WAL em outro nó, não só do recebimento. Isso exige monitoramento de três métricas críticas em tempo real: pg_stat_replication.sync_state (para confirmar se o standby está realmente em 'sync'), pg_wal_lsn_diff entre primary e standby, e o tempo de resposta do ZooKeeper ao tentar adquirir o lock de líder. Sem isso, você troca perda de dados por latência cega.

Em abril, a CEVIU já havia reportado que a Datadog migrava cargas pesadas de Postgres para outros stacks, como na otimização da página de métricas (06/04). Mas ali era uma questão de desempenho de consulta. Agora, em 19/06, a mudança é de política de consistência: de async replication + lag threshold para sync replication + remote_apply. Não é mais 'quanto posso tolerar de atraso?', mas 'quanto posso garantir que não haverá divergência?'. A diferença prática? Antes, um gameday com latência de rede travava o cluster. Agora, o mesmo cenário faz o leader rejeitar transações antes mesmo de elas serem confirmadas, e o failover ocorre em segundos, com RPO=0.

Isso importa porque sua equipe de SRE provavelmente ainda opera com maximum_lag_on_failover = 100MB e synchronous_commit = on, achando que está seguro. Mas 'on' não garante aplicação, só confirmação de recebimento. Em Kubernetes, onde redes são compartilhadas, esse gap entre 'recebido' e 'aplicado' é onde moram os incidentes pós-failover. Se seu backup usa pg_basebackup sem validar o LSN aplicado no standby, você pode estar restaurando um snapshot inconsistente sem saber. E se seu runbook de DR ainda pressupõe que 'uma réplica é sempre promovível', ele está obsoleto desde junho de 2026.