Redundância que funciona

Intermediário14 min de leituraconfiabilidade

Redundância é a resposta reflexa para confiabilidade: se um pode falhar, tenha dois. A ideia está certa e a execução costuma estar errada — porque duplicar o componente sem eliminar a correlação entre as cópias, e sem exercitar a troca, produz custo dobrado com disponibilidade quase igual.

Ativa e passiva

Ativa (ativo-ativo): todas as instâncias atendem tráfego ao mesmo tempo. A falha de uma é absorvida pelas outras, sem transição. Exige que a carga caiba nas que sobram — se duas instâncias operam a 60% cada, a perda de uma leva a outra a 120%, e você troca uma falha por duas.

Passiva (ativo-passivo): uma instância atende, a outra espera. Mais simples e mais barata, com dois riscos: o standby pode estar em estado desconhecido (nunca exercitado), e a transição leva tempo.

A regra de dimensionamento é a mesma dos dois lados: planeje o N-1. Se um nó, uma zona ou uma instância cair no pico, o que sobra atende? Se a resposta for não, sua redundância é decorativa.

O caminho de failover também falha

O ponto que mais causa surpresa: a redundância adiciona um componente novo — o mecanismo de troca — e ele tem a própria taxa de falha.

Modos de falha do failover que aparecem em incidentes reais:

Não dispara: o monitor não detectou (o caso da falha cinza).
Dispara sem necessidade: uma oscilação de rede provoca troca desnecessária, e a troca causa impacto.
Split-brain: os dois lados se acham primários e aceitam escrita divergente.
Alterna repetidamente: troca de ida e volta, piorando tudo.
O standby não sobe: configuração defasada, licença expirada, capacidade insuficiente na zona.

É por isso que quórum (número ímpar de observadores) e isolamento do nó antigo (fencing) não são detalhe de implementação: são o que impede que a solução vire o problema.

Domínios de falha e correlação

Redundância só entrega quando as cópias não compartilham o modo de falha. Vale perguntar, para cada camada, o que as cópias têm em comum:

Redundância	Protege de	Não protege de
Réplicas no mesmo nó	processo morrendo	falha do nó
Réplicas em nós diferentes	falha de nó	falha de zona
Multi-zona	falha de zona	erro de configuração global, bug de versão
Multi-região	falha de região	erro humano replicado, comprometimento de conta
Multi-nuvem	falha do provedor	complexidade que você acabou de criar

Observe onde a tabela para: nenhuma linha protege de deploy ruim, configuração errada ou comando destrutivo — que são as causas mais frequentes de indisponibilidade. Contra essas, o que funciona é lote pequeno, canário, rollback rápido e backup imutável.

Multi-nuvem merece uma nota cética: ela dobra a superfície operacional, impede usar serviços gerenciados de forma plena e adiciona um denominador comum novo — a camada de abstração que você escreveu. Para a grande maioria dos casos, multi-região no mesmo provedor entrega mais confiabilidade por menos complexidade.

Redundância não é backup

Réplica replica tudo, inclusive o erro. Um DELETE sem WHERE chega à réplica em milissegundos; um ransomware criptografa o que a credencial alcança.

As três proteções são distintas e não se substituem: redundância cobre falha de componente, backup cobre erro humano e corrupção, DR cobre perda de região. Um time com replicação síncrona impecável e sem restore testado está descoberto no cenário mais provável.

Testar o failover ou não tê-lo

Failover não exercitado é uma hipótese cara. A prática mínima:

Exercite em produção, em janela combinada, pelo menos por semestre.
Meça o tempo real de indisponibilidade durante a troca — ele quase nunca é o estimado.
Observe a aplicação, não só a infraestrutura: muitas aplicações não reconectam sozinhas depois do failover do banco, e esse é o achado mais comum do exercício.
Alterne quem executa, para não depender de uma pessoa.

Se a ideia de exercitar o failover em produção assusta, essa é a informação: você não tem redundância confiável, tem uma expectativa. Melhor descobrir numa terça de manhã, com o time reunido.