Decisão: qual solução de HA/DR?

A escolha de uma solução de alta disponibilidade e recuperação de desastres não começa pela tecnologia, mas pelo equilíbrio entre os requisitos de negócio (RTO/RPO), a necessidade de distribuição geográfica e o custo. A partir da sua tolerância a indisponibilidade e perda de dados, esta árvore indica a abordagem correta entre réplicas síncronas, standbys assíncronos, clusters com failover automático e backup+PITR.

Qual é a sua tolerância a perda de dados (RPO)?

Comece pela restrição mais rígida: em um desastre, quantos segundos de dados você pode se dar ao luxo de perder? Se for exigida perda de dados zero (RPO=0), a replicação síncrona é obrigatória; se alguns segundos/minutos forem aceitáveis, abrem-se soluções assíncronas e abordagens mais baratas. A meta de RPO geralmente orienta todas as outras decisões.

• Perda de dados zero é obrigatória (RPO = 0)
• Alguns segundos/minutos de perda de dados são aceitáveis

Também é exigida assunção automática e rápida (RTO baixo)?

Você quer perda de dados zero; mas com que rapidez precisa voltar quando o primário cair? Failover automático em segundos, ou uma breve janela de intervenção manual é aceitável? Isso define a diferença entre uma réplica síncrona simples e um cluster totalmente automatizado.

• É necessário failover automático em segundos
• Assunção manual/planejada basta; perda zero vem primeiro

É necessária outra região/geografia (DR)?

Se alguma perda de dados for aceitável, a verdadeira questão é o escopo da resiliência: é preciso se proteger contra a perda de um data center/região inteiro, ou basta a proteção contra a falha de um único nó na mesma região? Se a distribuição geográfica for necessária, o standby assíncrono ganha destaque; caso contrário, avaliam-se opções que priorizam o custo.

• Sim, uma região separada contra desastres geográficos é obrigatória
• Não, orçamento e simplicidade vêm primeiro

Você aceita um tempo de recuperação longo (RTO alto)?

Você vai ficar em uma única região e tolera alguma perda de dados. Seu objetivo é o menor custo, ou você quer um nó standby que assuma rapidamente em caso de falha? Se uma recuperação de horas for aceitável, apenas backup+PITR é o caminho mais econômico; caso contrário, você precisa de um warm standby.

• Sim, uma recuperação de horas é aceitável (mais barato)
• Não, é necessário um warm standby que assuma em minutos

Recomendação: réplica síncrona (perda de dados zero)

O primário não conclui um commit até que pelo menos um standby o confirme; assim, mesmo que o primário seja perdido, nenhuma transação confirmada é perdida (RPO=0). A solução ideal dentro de uma região, em uma rede de baixa latência.

Recomendação: standby assíncrono (DR geográfico)

O standby aplica as alterações como um fluxo, sem atrasar os commits do primário. É a forma padrão de manter uma cópia em outra região sem prejudicar o desempenho de gravação; em troca, aceita-se uma pequena janela de perda de dados (igual ao lag de replicação).

Recomendação: cluster com failover automático

Uma solução de cluster que combina monitoramento de saúde, eleição de líder e assunção automática; visa tanto RTO baixo (failover automático em segundos) quanto RPO baixo/zero com uma cópia síncrona. A sobrecarga operacional é maior, mas a intervenção humana é minimizada.

Recomendação: backup + PITR (mais econômico)

Em vez de um standby em execução, mantêm-se apenas backups regulares e recuperação point-in-time (PITR) via WAL/logs arquivados. É a solução de menor custo; o preço é que a recuperação pode levar horas (RTO alto).