Failover

Visão Geral

Failover é a troca do componente principal para uma cópia reserva quando o principal falha.

É o que transforma redundância de diagrama em disponibilidade real. E é o momento mais arriscado da vida de um sistema redundante: um failover mal executado causa mais dano que a falha original.

A frase que resume o problema desta área: um failover que nunca foi exercitado não é um plano, é uma esperança.

Problema

O caminho de failover é, por definição, raro. Ele é escrito uma vez, documentado, e raramente executado.

Quando é acionado, descobre-se que:

A cota na região secundária não permite subir a capacidade. A configuração divergiu ao longo do ano. Um certificado expirou porque ninguém monitorava o que não era usado. O procedimento tem catorze passos e cinco estão desatualizados. A pessoa de sobreaviso nunca o executou.

Nada disso é hipotético — é a lista recorrente dos post-mortems dessa categoria.

Conceitos Centrais

Automático ou manual

automático  rápido, sem espera por decisão
            risco de acionar em falso positivo
manual      decisão humana, sem acionamento indevido
            minutos ou horas de latência, dependente de disponibilidade da pessoa

A escolha depende do custo relativo dos dois erros: acionar sem necessidade contra demorar a acionar.

Para componentes sem estado, automático é claramente melhor — o custo de um acionamento indevido é baixo.

Para bancos de dados com replicação assíncrona, o cálculo muda: um failover indevido pode perder escritas e criar divergência. Muitos times mantêm manual por isso, e o preço é o tempo de resposta humana.

O meio-termo comum: automático com histerese — exigir falha sustentada por um período, não um pico instantâneo. Ver detecção de falhas.

Cérebro dividido é o pior resultado

Duas cópias se consideram principais. Ambas aceitam escrita. Os dados divergem, e a reconciliação é manual e imperfeita.

Isso é pior que indisponibilidade: indisponibilidade se resolve; divergência de dados pode não se resolver.

Os mecanismos que impedem:

Maioria. Só assume quem tem o voto da maioria dos nós. Por isso três, não dois. Ver consenso.

Isolamento do antigo. O primário anterior é impedido de aceitar escrita — por revogação de credencial, por regra de rede, ou por desligamento.

Marca de geração. Escritas carregam um número de geração; o armazenamento recusa as de geração antiga.

Um failover sem nenhum desses mecanismos vai produzir cérebro dividido eventualmente.

O que se perde na promoção

Com replicação assíncrona, o que o primário confirmou e não replicou se perde.

atraso de replicação de 2s no momento da falha
  → até 2 segundos de escritas confirmadas ao usuário, perdidas

Isso precisa ser conhecido e aceito. Ver RPO.

E precisa ser comunicado: transações confirmadas ao usuário que deixaram de existir geram um problema de negócio, não apenas técnico.

Retornar ao primário é outro failover

Depois que o componente original volta, retornar a ele é uma operação de risco equivalente.

O erro característico: tratar o retorno como "voltar ao normal" e executá-lo sem o mesmo cuidado — durante o horário de pico, sem janela, sem verificar que o antigo primário está de fato consistente.

Muitos incidentes de failover têm duas partes, e a segunda é o retorno.

Uma decisão que simplifica: não retornar. Se as cópias são equivalentes, a que assumiu permanece como principal, e a antiga vira reserva. Isso elimina metade do risco.

Dependências precisam acompanhar

Promover o banco não basta se a aplicação continua apontando para o antigo.

O failover completo envolve: descoberta de serviço, cadeias de conexão, DNS com tempo de vida curto, filas, agendadores, e sistemas externos que apontam para o endereço antigo.

O item de DNS merece nota: um tempo de vida de uma hora é o piso otimista do que os clientes levarão para mudar. Resolvedores intermediários e caches de biblioteca frequentemente excedem o valor declarado, e conexão já estabelecida não reconsulta DNS nenhum — ela segue no endereço antigo até cair.

Inventariar tudo que aponta para o componente é parte do desenho, e é o que costuma faltar.

Exercitar é a única verificação que vale

Ver engenharia do caos. O failover precisa ser executado periodicamente, em produção, em janela controlada.

A primeira execução encontra problemas. A terceira ou quarta, geralmente não. E o tempo de execução cai substancialmente com a prática — porque o procedimento fica correto e as pessoas ficam confortáveis.

Um failover exercitado mensalmente é uma operação de rotina. Um exercitado nunca é um incidente dentro de um incidente.

Modelo Mental

Failover é um procedimento, não uma configuração. Ele funciona se for executado regularmente, e falha se for só documentado.

Quando Usar

• Existe redundância com cópia reserva.
• A indisponibilidade tem custo que justifica a complexidade.
• Há requisito de tempo de recuperação. Ver RTO.
• Manutenção precisa acontecer sem parada.

Quando Não Usar

Sem exercitar.

Automático sem mecanismo contra cérebro dividido.

Automático para banco com replicação assíncrona, sem aceitar a perda.

Sem inventariar o que aponta para o componente.

Retornar ao primário sem o mesmo cuidado.

Quando recuperar o original é mais rápido que trocar.

Alternativas

• Ativo-ativo — sem troca a executar; o caminho de recuperação é o normal. Ver redundância.
• Recuperação rápida — reiniciar ou recriar o componente, em vez de trocar.
• Degradação graciosa — operar sem o componente.
• Failover manual com procedimento ensaiado — mais lento e mais previsível.

Trade-offs

Automático	Manual
Segundos	Minutos a horas
Risco de falso positivo	Sem acionamento indevido
Sem dependência humana	Depende de sobreaviso
Exige proteção contra cérebro dividido	Decisão humana filtra

Retornar	Permanecer
Volta à topologia planejada	Assimetria aceita
Segundo risco	Um risco a menos
Cópias podem ser desiguais	Exige equivalência

Modos de Falha

Cérebro dividido.

Cota insuficiente na reserva.

Configuração divergente.

Certificado expirado na reserva. Nunca usado, nunca monitorado.

Perda de escritas na promoção.

Dependências apontando para o antigo.

Procedimento desatualizado.

Falso positivo. Failover acionado por uma oscilação de rede.

Erros Comuns

Não exercitar. É o mecanismo que só roda sob estresse. Um procedimento nunca executado costuma falhar na primeira tentativa — e a primeira tentativa, por definição, acontece durante o incidente.

Duas cópias em vez de três, impedindo maioria. Com duas, nenhum lado consegue formar maioria durante uma partição, e a promoção automática vira aposta entre parar tudo ou arriscar cérebro dividido.

Não isolar o primário antigo. Se ele volta sem saber que foi substituído, passa a aceitar escritas em paralelo com o novo. É a via clássica de divergência de dados.

Não monitorar a saúde da reserva. Uma réplica com replicação parada há dias parece disponível e promove um estado antigo — descobre-se depois de promover.

DNS com tempo de vida longo. O failover acontece em segundos e os clientes continuam indo ao endereço antigo pelo tempo de cache, que pode ser dezenas de minutos.

Tratar o retorno como operação trivial. Voltar ao primário original exige ressincronizar dados escritos durante a contingência, e é frequentemente mais delicado que o failover em si.

Exemplo Real

Uma instituição financeira tinha failover automatizado de banco entre duas zonas, documentado e nunca exercitado em três anos.

Numa falha real da zona primária, o failover foi acionado automaticamente e produziu o pior resultado possível.

A sequência:

Promoção bem-sucedida. A réplica assumiu em 25 segundos.

Aplicações não reconectaram. As instâncias mantinham conexões para o endereço antigo e não tinham lógica de reconexão. Foi preciso reiniciá-las manualmente: 12 minutos.

Primário antigo voltou. A zona se recuperou parcialmente, e o banco original voltou a aceitar conexões — ainda se considerando primário. Não havia mecanismo de isolamento.

Cérebro dividido por 40 minutos. Parte das aplicações, reiniciadas antes, apontava para o novo primário; parte, para o antigo. Ambos aceitaram escrita.

Divergência de dados. 1.400 transações precisaram ser reconciliadas manualmente ao longo de três dias. Dezenove não puderam ser resolvidas com certeza.

A reformulação:

Três nós, com maioria. A promoção passou a exigir quórum, o que impede uma segunda promoção — o antigo primário não consegue ser eleito de novo. Não é isso que o cala: sozinho, o quórum o deixaria continuar se achando primário e aceitando escrita, que foi exatamente a falha. Quem fecha essa porta é o item seguinte.

Isolamento por revogação. A credencial do primário antigo é revogada na promoção, antes de qualquer outra coisa.

Reconexão automática nas aplicações, com descoberta de serviço em vez de endereço fixo.

Exercício mensal, em produção, em janela de baixo movimento. O primeiro levou 18 minutos e encontrou quatro problemas; o sexto levou 40 segundos e não encontrou nenhum.

Não retornar. A cópia que assume permanece como primária. As três são equivalentes e a assimetria deixou de existir.

O que a equipe registra, com a distinção que custou 40 minutos para aprender: a detecção e a promoção funcionaram como projetadas, em 25 segundos. O que faltava não era periferia — era o resto do mecanismo de troca: quórum e isolamento, sem os quais promover uma réplica num desenho de duas cópias produz dois primários por construção. Em volta disso, três coisas que ninguém tinha inventariado: o tempo de vida do DNS, as conexões abertas e as aplicações sem reconexão. Nenhuma é defeito do produto de banco de dados; todas são do desenho de failover.

Conceitos Relacionados

• Redundância — o pré-requisito.
• Engenharia do Caos — o exercício.
• Eleição de Líder — o cérebro dividido.
• RPO — o que se perde.

Exercício Prático

Descubra quando o failover do seu componente mais crítico foi exercitado pela última vez.

Se a resposta for "nunca", agende um — e reserve o dobro do tempo que você imagina que vai levar.

Perguntas de Entrevista

• Por que cérebro dividido é pior que indisponibilidade?
• Por que o retorno ao primário é um segundo risco?
• O que precisa acompanhar a promoção, além do componente em si?

Para Aprofundar

• Kleppmann, Martin. Designing Data-Intensive Applications. O'Reilly, 2017 — capítulo 5.
• Beyer, Betsy et al. Site Reliability Engineering. O'Reilly, 2016.
• Nygard, Michael. Release It!. 2ª ed. Pragmatic Bookshelf, 2018.