TL;DR: A Microsoft tornou geralmente disponível o service-managed failover no Azure DocumentDB, automatizando a recuperação de falhas regionais sem intervenção humana. Para empresas brasileiras, isso reduz o RTO em cenários de indisponibilidade, mas com trade-off de possível perda de pequenas escritas não replicadas. É complementar à alta disponibilidade intra-região, não substituta. A escolha entre graceful promotion e service-managed failover depende do seu apetite por perda de dados versus velocidade de recuperação.
A Microsoft anunciou a disponibilidade geral do service-managed failover no Azure DocumentDB — o banco de dados documental gerenciado compatível com MongoDB. A novidade elimina a necessidade de intervenção humana para se recuperar de uma falha regional, algo que, até então, exigia monitoramento manual e ação para promover um cluster réplica.
Para times de infraestrutura no Brasil, onde a latência entre regiões Azure (ex.: Brazil South para East US) e a criticidade de aplicações financeiras ou de e-commerce tornam cada segundo de downtime caro, essa automação pode representar uma redução significativa no RTO (Recovery Time Objective). Mas a solução não é isenta de trade-offs.
Como funciona o novo failover automático?
O Azure DocumentDB já oferece replicação cross-region, permitindo manter um cluster réplica em uma região secundária. O cluster primário (Região A) lida com todas as leituras e escritas, enquanto o réplica (Região B) se mantém sincronizado de forma assíncrona e pode atender tráfego de leitura.
Com o service-managed failover, o serviço passa a monitorar continuamente a saúde da região primária. Se identificar que a região primária está indisponível e que a recuperação local entre zonas não é possível, ele automaticamente promove o cluster réplica. A connection string global de leitura/escrita é atualizada internamente para apontar para o novo primário, sem exigir alterações na aplicação.
Ponto de atenção: internamente, isso se comporta como uma forced promotion — como o primário está inacessível, a fila de replicação não pode ser completamente drenada antes da troca. Isso significa que escritas confirmadas no primário, mas ainda não replicadas no momento da falha, podem ser perdidas. Em troca, você ganha recuperação automática e rápida, sem envolvimento humano.
Escolhendo o modo de failover adequado
O service-managed failover é uma das três formas de promover um cluster réplica. Entender as diferenças é essencial para decidir qual postura adotar.
| Modo | Gatilho | Zero Data Loss | Automático |
|---|---|---|---|
| Graceful promotion | Usuário | ✅ Sim | ❌ Não |
| Forced promotion | Usuário | ❌ Não | ❌ Não |
| Service-managed failover | Automático (Azure DocumentDB) | ❌ Não | ✅ Sim |
Se a sua workload exige zero perda de dados, a graceful promotion — que drena a fila de replicação antes da troca — continua sendo a escolha correta para failovers planejados (ex.: manutenção, migração). Para falhas regionais imprevistas, onde a velocidade de recuperação pesa mais que o risco de perder algumas escritas não replicadas, o service-managed failover oferece proteção hands-free.
O que você precisa para habilitar
O service-managed failover é um recurso opt-in, desabilitado por padrão. Para utilizá-lo:
- Certifique-se de ter a replicação cross-region configurada com um cluster réplica em uma região secundária.
- Ative a configuração via ticket de suporte (a ativação pelo portal será disponibilizada em breve).
- Utilize a connection string global de leitura/escrita na sua aplicação, que será atualizada automaticamente durante o failover.
Nenhuma outra alteração na aplicação é necessária.
HA intra-região e DR cross-region: melhor juntos
O service-managed failover resolve falhas regionais, mas não substitui a alta disponibilidade (HA) intra-região. A HA protege contra falhas de shard dentro de uma mesma região, mantendo um shard síncrono em standby com failover automático e zero perda de dados. Habilitar ambos oferece proteção em camadas:
- HA trata falhas de nó dentro da região primária automaticamente, sem perda de dados.
- Service-managed failover trata falhas de região inteira automaticamente, com perda mínima de dados.
Para workloads de produção, a configuração recomendada é utilizar ambos.
Conclusão
A chegada do service-managed failover no Azure DocumentDB é um passo relevante para simplificar a continuidade de negócios em cenários de indisponibilidade regional. Para empresas brasileiras que operam com réplicas em regiões secundárias (como East US para Brazil South), a automação reduz o tempo de resposta e a dependência de operações manuais — algo crítico em horários de pico ou fora do horário comercial.
Porém, o trade-off de perda potencial de dados não replicados deve ser avaliado caso a caso. Se a sua aplicação exige consistência forte mesmo após uma falha regional, o caminho ainda é o failover manual com graceful promotion. Para a maioria dos cenários de alta disponibilidade web, o service-managed failover será o equilíbrio ideal entre velocidade e simplicidade.
Perguntas Frequentes
-
O que é service-managed failover no Azure DocumentDB?
É um recurso que automatiza a promoção de um cluster réplica em uma região secundária quando a região primária fica indisponível. O serviço monitora continuamente a saúde da região primária e, ao confirmar uma falha regional, promove automaticamente o cluster réplica como novo primário, atualizando a connection string global sem intervenção humana. -
Qual a diferença entre service-managed failover e graceful promotion?
Graceful promotion é iniciada manualmente pelo usuário e drena toda a fila de replicação antes da troca, garantindo zero perda de dados, mas exige ação humana e mais tempo. Já o service-managed failover é automático, mas pode perder escritas que estavam no buffer de replicação no momento da falha. A troca é mais rápida, porém sem garantia de zero data loss. -
Quando devo usar cada modo de failover?
Use graceful promotion para failovers planejados (ex.: manutenção ou migração) onde zero perda de dados é crítico. Use service-managed failover para falhas regionais não planejadas, onde a velocidade de recuperação (RTO baixo) é mais importante do que evitar a perda de algumas escritas não replicadas. Forced promotion é uma opção manual de emergência, sem automação e sem zero data loss. -
Preciso configurar algo além de ativar o service-managed failover?
Sim, é necessário ter replicação cross-region configurada com um cluster réplica em uma região secundária. O recurso é opt-in (desabilitado por padrão) e atualmente a ativação é feita via ticket de suporte (portal em breve). Use a connection string global de leitura/escrita para que a aplicação seja redirecionada automaticamente durante o failover. Nenhuma outra alteração na aplicação é necessária. -
Como o service-managed failover se combina com a alta disponibilidade intra-região?
Eles são complementares. A HA intra-região protege contra falhas de shard dentro da mesma região, com failover automático e zero perda de dados. O service-managed failover protege contra falhas regionais completas, com failover automático mas perda mínima de dados. Para workloads de produção, a recomendação é habilitar ambos para proteção em camadas.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
