Alta disponibilidade no PostgreSQL: replicação, Patroni e failover

Alta disponibilidade não é ter uma réplica. É garantir que a aplicação continue funcionando quando um servidor falha, com perda de dados dentro do aceitável e tempo de recuperação conhecido. Isso exige arquitetura, automação e teste.

Comece por RPO e RTO

RPO é quanto de dados você aceita perder em uma falha. RTO é quanto tempo a operação pode ficar indisponível. Esses dois números definem a arquitetura: replicação síncrona ou assíncrona, quantidade de réplicas, necessidade de quorum e orçamento.

• RPO zero: replicação síncrona, com impacto na latência de escrita
• RPO de segundos: replicação assíncrona com monitoramento de lag
• RTO de minutos: failover automatizado e aplicação com reconexão
• RTO maior: procedimento manual documentado e ensaiado

Streaming replication

O primário envia o WAL para as réplicas, que aplicam as alterações. A réplica pode atender leitura, mas não aceita escrita até ser promovida. O atraso de aplicação do WAL é o lag, que precisa ser monitorado antes de afetar relatórios e decisões.

SELECT client_addr, state, sent_lsn, replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
FROM pg_stat_replication;

Patroni e quorum

Patroni coordena a eleição do primário usando um armazenamento de consenso, como etcd. Com quorum, o cluster evita que dois nós se promovam ao mesmo tempo. A configuração precisa definir quem pode promover, como a aplicação encontra o primário e o que acontece quando o nó antigo volta.

Failover precisa ser testado

O teste de failover é o que separa configuração de operação. Simule queda do primário, meça o tempo até a aplicação voltar, valide escrita e leitura e verifique se o nó antigo retorna como réplica sem divergência. Faça isso em janela controlada e registre o resultado.

• Derrubar o primário e medir RTO real
• Validar que a aplicação reconectou sem intervenção manual
• Conferir replicação e lag após a promoção
• Testar o retorno do nó antigo ao cluster
• Revisar alertas e runbook com o que o teste revelou

Erros comuns

• Réplica que nunca foi promovida em teste
• Aplicação apontando para IP fixo do primário
• Lag alto tratado como normal
• Falta de quorum e risco de split-brain
• Backup dependente do mesmo servidor do banco
• Runbook desatualizado ou sem dono

Conclusão

Alta disponibilidade é um contrato com a operação: RPO, RTO e procedimento claro. A tecnologia é parte; o teste é o que prova que funciona. Se a sua réplica nunca foi promovida, o ambiente ainda não tem alta disponibilidade — tem uma cópia.