Failover automático: as 4 etapas da comutação, 7 modos de falha e o failback

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado dez/2025Atualizado set/2026

O health check falhou três vezes seguidas. Em seguida, o cluster promove o nó de reserva, o balanceador tira o antigo primário do pool e o serviço volta a responder. Num laboratório com dois nós, a troca do endereço virtual levou 3,3 segundos.

A pergunta que interessa depois disso não é o significado da palavra. É quantos segundos o serviço ficou fora durante a troca e quanto dado ficou para trás. Além disso, o que acontece quando o próprio mecanismo erra. Vale somar uma quarta pergunta: por que o ensaio de contingência devolve um número bom demais.

O Uptime Institute já mediu essa conta. Na pesquisa anual de 2025, 57% dos respondentes disseram que a última interrupção passou de US$ 100 mil, segundo o levantamento de 2026.

Este texto trata do mecanismo, não do plano. Meta de recuperação, estratégias de contingência e roteiro de retomada moram no plano de disaster recovery. Aqui ficam as quatro etapas da comutação, os sete modos pelos quais ela falha e a razão de a volta custar mais que a ida.

O que é failover e o que ele executa em quatro etapas

Failover é a comutação automática de um serviço para um nó de reserva depois que o sistema detecta a falha do nó principal. Em português técnico, é comutação por falha. Diferente do backup, que protege o dado parado, ele protege o serviço em operação. Ou seja, não recupera informação: muda quem responde pela carga.

A confusão começa antes de qualquer configuração. O failover não é um evento instantâneo nem uma chave que alguém vira. É uma sequência de quatro etapas, cada uma com o próprio consumo de relógio. O tempo total de indisponibilidade é a soma delas.

Vale destacar que apenas a etapa 3 depende do software de banco ou de aplicação. As outras três dependem de configuração de monitoramento, de topologia de rede e de decisões que alguém tomou meses antes do incidente.

Failover, failback, switchover e fallback: qual é qual

Os quatro termos aparecem juntos na mesma discussão e descrevem coisas diferentes. Trocar um pelo outro em um runbook custa caro no meio da madrugada, porque a ação esperada muda por completo.

Por fim, a distinção que mais gera erro é a última. Fallback não é a volta para casa: é a degradação controlada que mantém a aplicação de pé enquanto o componente de baixo está fora. Um sistema pode passar o dia inteiro em fallback sem nunca ter feito failover.

Failover automático ou manual: o critério que decide

Automatizar a comutação nem sempre é a resposta melhor. O critério não é o tamanho da empresa nem a criticidade declarada do serviço: é a comparação entre o dano de comutar por engano e o dano de esperar por uma pessoa.

Automatize quando as quatro condições abaixo forem verdadeiras ao mesmo tempo.

• A assinatura da falha é inequívoca, ou seja, o teste distingue nó morto de nó lento.
• Existe árbitro externo capaz de impedir dois primários simultâneos.
• O secundário aguenta a carga inteira, não só a fração que costuma receber.
• Desfazer a decisão é barato caso ela esteja errada.

Por outro lado, se alguma dessas condições falhar, mantenha a decisão com uma pessoa. Réplica de banco com replicação assíncrona é o exemplo clássico: promover automaticamente uma réplica atrasada troca uma indisponibilidade de dez minutos por uma perda de transações que ninguém consegue reconstruir depois.

Comutação entre regiões geográficas segue a mesma lógica. O raio de impacto de uma decisão errada nesse escopo costuma superar o custo de mais quinze minutos de análise. Portanto, ela raramente compensa como reação automática.

Failover por camada: onde o relógio realmente corre

A pergunta “quais são os tipos de failover” tem uma resposta mais útil quando se troca a taxonomia comercial pela camada da pilha. Cada camada tem o próprio mecanismo de troca e o próprio gargalo de tempo.

DNS: o atraso que você não controla

Quando o site inteiro cai, a troca acontece no nome, não no IP. O problema é que o cliente já guardou a resposta antiga: enquanto o cache de DNS não expirar, ele continua batendo no endereço morto.

Um TTL de 300 segundos vira piso de indisponibilidade. Pior: resolvedores que ignoram TTL baixo esticam esse piso ainda mais.

Por isso arquiteturas sérias de múltiplos sites usam endereço anycast ou balanceador global, em vez de depender da propagação de registro.

Balanceador e IP virtual: a troca em segundos

Dentro da mesma rede, a comutação é rápida porque não envolve resolução de nome. Em seguida, o IP virtual muda de máquina e um anúncio ARP gratuito avisa os vizinhos. Nesse escopo, o tempo perdido está quase todo na etapa de detecção, não na de redirecionamento.

Em Linux, quem executa essa troca costuma ser o keepalived, que fala o protocolo VRRP. Nele, dois parâmetros decidem o relógio inteiro da camada.

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150              # o maior valor manda no par
    advert_int 1                # um anúncio por segundo
    unicast_peer {
        172.30.0.12           # o nó de reserva
    }
    virtual_ipaddress {
        172.30.0.100/24       # o endereço que o cliente procura
    }
}

O advert_int define o intervalo entre os anúncios do primário. Além disso, a priority entra no desempate. Antes de assumir, a reserva espera três anúncios perdidos mais um atraso de (256 - priority) / 256 segundos.

Com prioridade 100, esse atraso vale 0,6 segundo e o total chega a 3,6. O laboratório confirma o número: em 3 de setembro de 2026, com keepalived 2.3.1, o cliente ficou 3,3 segundos sem resposta. Ou seja, o redirecionamento em si não aparece no relógio.

Aplicação e orquestrador: reiniciar pod não é comutar serviço

Em ambiente de containers, por exemplo, o orquestrador mata a réplica que travou e sobe outra. Vale distinguir os dois comportamentos: reiniciar uma instância sem estado é barato, enquanto promover um componente com estado exige coordenação.

O monitoramento de Kubernetes precisa separar as duas coisas, porque um pod que reinicia a cada dez minutos aparece como saudável no painel do cluster.

O comportamento das sondas está descrito na documentação oficial do projeto, que separa sonda de vivacidade de sonda de prontidão exatamente por esse motivo.

Banco de dados: a replicação decide o que se perde

Aqui está a decisão mais cara da pilha. Com replicação síncrona, a transação só confirma depois de gravada nos dois lados. Em troca, isso zera a perda de dado e cobra latência em toda escrita.

Com replicação assíncrona, a escrita é rápida e a réplica fica atrasada por um intervalo variável. Esse atraso é exatamente o que se perde na promoção.

Na operação das Lojas Marisa, acompanhamos os bancos Oracle em 433 lojas monitoradas a partir do datacenter. Entre os indicadores estão performance, disponibilidade, armazenamento, segurança e replicação. Ou seja, o atraso de replicação é o que separa uma promoção previsível de um salto no escuro.

Sem essa medição no monitoramento de banco de dados, ninguém sabe qual é a perda real no instante em que aperta o botão. O número acordado em contrato descreve a intenção; o atraso medido no minuto anterior descreve o que vai acontecer.

Cada camada, portanto, tem o próprio orçamento de detecção. Esse orçamento vem de valores padrão que quase ninguém revisa. A tabela reúne quatro mecanismos dessas camadas, com o que cada um espera antes de declarar a falha.

Todos os números acima saíram do software em execução ou da referência oficial do fabricante, em setembro de 2026. Nenhum deles é limite físico: todos são configuração. Em contrapartida, quem baixa o intervalo compra detecção mais rápida e paga em falso positivo.

Os 7 modos de falha do failover

Todo material sobre o assunto descreve o mecanismo funcionando. A operação, no entanto, encontra o mecanismo quebrado. Por isso, os sete modos abaixo cobrem a maioria dos casos em que a comutação existia, estava configurada e mesmo assim não salvou o serviço.

Vale destacar que os dois primeiros são de outra natureza. Eles não causam indisponibilidade: causam divergência de dado, que é pior, porque o serviço continua respondendo enquanto acumula inconsistência silenciosa. Em ambientes de cluster de virtualização, o cercamento do nó suspeito é o recurso que fecha essa porta.

O primeiro deles é fácil de reproduzir. Basta cortar o tráfego de VRRP entre os dois nós do laboratório. Em seguida, ambos passam a carregar o mesmo endereço virtual.

# a rede entre os dois nós cai: cada um deixa de ouvir o outro
$ docker exec fo-no2 iptables -A INPUT -p 112 -j DROP

# oito segundos depois, os dois carregam o mesmo endereço
$ docker exec fo-no1 ip -4 addr show eth0 | grep 172.30.0.100
    inet 172.30.0.100/24 scope global secondary eth0
$ docker exec fo-no2 ip -4 addr show eth0 | grep 172.30.0.100
    inet 172.30.0.100/24 scope global secondary eth0

# e nenhum dos dois acusa erro
$ docker logs fo-no2 | tail -1
(VI_1) Entering MASTER STATE

Repare que nenhum dos dois acusa erro. Com dois votos não existe maioria, então cada lado conclui que o outro morreu. É por isso que o quórum pede número ímpar e que a testemunha externa existe.

O health check que dispara: por que o gatilho erra

A automação da comutação depende inteiramente da qualidade da verificação de saúde. Um gatilho que confunde lentidão com morte transforma o mecanismo de proteção em fonte de incidente. Além disso, cada comutação desnecessária custa uma janela de reconexão para todos os clientes.

Antes de tudo, o erro mais comum é testar a camada errada. Responder ao ping prova que a máquina tem rede. Aceitar conexão na porta prova que o processo subiu. Nenhum dos dois prova que o serviço funciona: um banco com disco cheio aceita conexão e recusa toda escrita.

Por isso, o teste que decide comutação precisa exercitar a transação real. Uma consulta pequena no banco, um login sintético ou uma chamada ao endpoint que o cliente usa: qualquer um deles distingue “processo vivo” de “serviço útil”. Vale medir também o tempo de resposta, porque degradação sem queda é o cenário que mais engana o gatilho binário.

Ainda assim, existe um equilíbrio a calibrar. Um teste severo demais dispara comutação por soluço de rede; um teste tolerante demais deixa o serviço fora do ar por minutos antes de reagir. A saída é exigir falhas consecutivas em uma janela de sustentação, em vez de mexer só no intervalo entre as verificações.

Existe ainda uma armadilha no próprio ensaio. Desligar o nó de forma ordenada não exercita o gatilho: o keepalived anuncia a saída com prioridade zero. Em seguida, a reserva assume sem esperar nada.

# o primário morre sem avisar ninguém
$ docker kill fo-no1
queda-abrupta-1    requisicoes=159 perdidas=32 fora_do_ar=3300 ms (assumiu no2)
queda-abrupta-2    requisicoes=159 perdidas=32 fora_do_ar=3306 ms (assumiu no2)
queda-abrupta-3    requisicoes=159 perdidas=32 fora_do_ar=3306 ms (assumiu no2)

# o mesmo nó, agora desligado de forma ordenada
$ docker stop fo-no1
parada-graciosa-1  requisicoes=159 perdidas= 0 fora_do_ar=   0 ms
parada-graciosa-2  requisicoes=159 perdidas= 0 fora_do_ar=   0 ms
parada-graciosa-3  requisicoes=159 perdidas= 0 fora_do_ar=   0 ms

Portanto, um ensaio que desliga o serviço pelo comando de parada mede a educação do software, não a detecção da falha. A queda real não avisa ninguém. Vale destacar que só o teste com o processo morto entrega o número do incidente.

Cluster instável e operação cansada andam juntos. O plantão paga essa conta. É o assunto do vídeo sobre o que ninguém comenta a respeito da operação 24/7.

A mesma disciplina que reduz fadiga de alertas serve para o gatilho de comutação: o alerta e a automação bebem da mesma coleta.

Failback: a volta custa mais que a ida

Quase toda operação testa a ida. Poucas testam a volta, embora ela seja a metade mais arriscada. Durante o tempo em que a contingência esteve ativa, o secundário acumulou transações que o primário original nunca viu.

Dessa forma, devolver o papel de primário sem reconciliar esse intervalo apaga trabalho real. Por isso o failback pede sincronização reversa completa, conferência de integridade e janela combinada.

A documentação de confiabilidade da Microsoft registra o mesmo ponto: a volta costuma exigir intervenção manual e tende a produzir mais indisponibilidade que a comutação original.

Além disso, há o estado do primário. Se alguém tentou correções nele durante o incidente, a máquina pode estar em condição desconhecida. Nesse caso, destruir e reconstruir a instância sai mais barato que confiar em um servidor com histórico duvidoso.

Em resumo, trate o failback como mudança planejada, com aprovação e horário definido. Ele entra no mesmo cálculo de MTTR e MTBF que a operação já reporta. Ignorar isso produz um número de recuperação que descreve só metade do ciclo.

O que conferir antes do próximo incidente

Failover configurado não é failover funcionando. A distância entre os dois estados aparece em quatro perguntas que a operação consegue responder hoje, sem esperar a próxima queda.

Primeiro: qual é o atraso de replicação médio da última semana, com limiar que bloqueie promoção acima dele? Segundo: o secundário já rodou sozinho com a carga de pico, ou só com a fração que recebe em regime? Terceiro: o gatilho testa transação ou testa porta? Quarto: quando foi o último failback ensaiado, com sincronização reversa incluída?

Ou seja, quem responde as quatro com número em mãos tem um mecanismo de comutação. Quem responde com estimativa tem um cluster que ainda não foi cobrado. A diferença entre os dois aparece uma vez só, no pior momento possível. A conta chega em minutos de serviço fora do ar.

Se você quer revisar o gatilho, a cobertura de monitoramento e os limiares que sustentam a comutação do seu ambiente, fale com nossos especialistas.