Multi-AZ e Failover

Multi-AZ é o esquema de implantação de alta disponibilidade do RDS e do Aurora: o serviço mantém, além do primário, um standby sincronizado em outra zona de disponibilidade da mesma região, e promove esse standby automaticamente quando o primário falha ou entra em manutenção. O failover é disparado pelo serviço, sem intervenção humana, e a troca acontece por atualização do endpoint DNS, de modo que as aplicações não precisam saber qual nó está no papel de escrita. O objetivo declarado é disponibilidade, não escala: o standby do Multi-AZ DB Instance não atende consultas, ao contrário da read replica. Em produção, Multi-AZ é frequentemente o mínimo aceitável para qualquer banco de dados que suporte operação de negócio, pois transforma a queda de uma zona inteira de um evento catastrófico em um incidente de pouco mais de um minuto.

Conceito e posição na arquitetura

A implantação Multi-AZ DB Instance mantém o primário em uma zona de disponibilidade e o standby em outra, com replicação síncrona no nível de bloco de armazenamento entre eles. Cada transação confirmada no primário já foi gravada no standby antes de receber commit, o que define o RPO zero para transações confirmadas. O standby fica invisível para as aplicações: sem endpoint próprio, sem leitura, sem conexões diretas; ele existe exclusivamente para assumir o papel de primário.

O Aurora tem uma filosofia diferente com o mesmo nome: seu armazenamento é distribuído em seis cópias em três zonas de disponibilidade, e a alta disponibilidade é obtida promovendo um reader existente a writer em vez de um standby dedicado. O conceito Multi-AZ DB Cluster tenta unir os dois mundos no RDS tradicional, com dois standbys legíveis e failover rápido. Entender essa gradação evita a confusão mais comum em provas e em projetos: Multi-AZ não é réplica de leitura, e réplica de leitura não é alta disponibilidade por si só.

O problema que resolve

Zonas de disponibilidade falham: eventos de energia, resfriamento e rede já tiraram zonas inteiras de provedores de nuvem do ar em incidentes reais. Sem Multi-AZ, a falha da zona onde o banco reside significa indisponibilidade total até intervenção manual, com promoção emergencial de uma réplica, reescrita de configuração e risco elevado de erro humano no meio da crise. Com Multi-AZ, o mesmo evento é resolvido pelo serviço em cerca de um a dois minutos.

O segundo problema é a janela de manutenção. Patches de segurança, upgrades de minor version e mudanças de classe de instância exigem reinício; em implantação Multi-AZ o serviço aplica a manutenção no standby primeiro, faz o failover, e então aplica no primário tornado standby, encurtando a janela de indisponibilidade para o tempo do próprio failover. O terceiro problema é a falha de hardware silenciosa: o serviço monitora a saúde do primário e substitui a instância defeituosa via failover antes que o cliente precise abrir ticket.

Há também um benefício de governança: Multi-AZ desloca a alta disponibilidade da esfera do time de aplicação para a esfera da plataforma. Sem ele, cada equipe precisa implementar detecção de falha, promoção e redirecionamento, e cada implementação tem bugs próprios; com ele, o contrato fica em usar o endpoint certo e tratar reconexão, um requisito muito mais simples de auditar.

Funcionamento do failover automático

O fluxo do failover segue uma sequência determinística. Primeiro, o serviço detecta a falha por health checks da instância e do processo do banco. Segundo, o standby sincronizado é promovido a primário; como a replicação era síncrona, não há transações confirmadas a perder. Terceiro, o serviço atualiza o registro DNS do endpoint do banco para apontar ao novo primário. Quarto, as aplicações reconectam usando o mesmo endpoint e retomam o tráfego.

A duração típica do failover em um Multi-AZ DB Instance fica entre 60 e 120 segundos, e no Multi-AZ DB Cluster a meta é menor, geralmente abaixo de 35 segundos, porque os standbys legíveis já mantêm cache e estado mais próximos do writer. Durante a janela, escritas falham com erro de conexão e é responsabilidade da aplicação tratar o evento com retry e reconexão; a seção de aplicação prática detalha esse contrato.

# Habilitar Multi-AZ em uma instância existente do RDS
aws rds modify-db-instance \
  --db-instance-identifier vendas-prod \
  --multi-az \
  --apply-immediately

# Teste controlado de failover: reinicia o primário forçando a troca de papel
aws rds reboot-db-instance \
  --db-instance-identifier vendas-prod \
  --force-failover

RTO e RPO

Os dois indicadores medem a qualidade de qualquer estratégia de failover e servem para comparar alternativas com números, não com impressões.

O RPO zero vale para transações confirmadas, e essa precisão importa. Uma transação em voo no momento da falha, cujo commit ainda não foi confirmado ao cliente, não é garantida; a aplicação deve tratar o erro e decidir se reenvia a operação, preferencialmente com idempotência. O RTO, por sua vez, depende também de fatores fora do serviço: tamanho do pool de conexões, velocidade de reconexão e presença de cache de DNS agressivo na aplicação.

A interpretação correta dos números é que eles se aplicam ao banco, não ao sistema. Um failover de 90 segundos com fila de requisições, cache frio e reconexão em massa pode degradar o serviço por vários minutos além do RTO do RDS, num efeito de fila que retarda a estabilização. Projetar para o RTO do sistema, e não só do banco, significa limitar taxa de retries, usar circuit breakers e prever drenagem ordenada do backlog de conexões.

Multi-AZ versus Read Replica

A comparação entre os dois recursos é o ponto de maior confusão no RDS, pois ambos replicam dados, mas com propósitos ortogonais.

A implantação de produção madura combina os dois: Multi-AZ como fundação de disponibilidade, com read replicas por cima quando a leitura satura. Réplicas do RDS podem inclusive ser criadas sobre instâncias Multi-AZ, herdando a alta disponibilidade do primário e adicionando a camada de escala de leitura.

Integração com réplicas e com Aurora

Topologias combinadas seguem uma hierarquia clara: o par primário e standby forma o núcleo, e as réplicas de leitura se conectam ao primário desse núcleo. Durante um failover, as réplicas associadas à instância Multi-AZ continuam replicando, pois o serviço redireciona o stream para o novo primário; a defasagem pode aumentar momentaneamente durante a reorganização, mas a topologia se recompõe sem ação manual. Esse comportamento é mais um argumento para manter os endpoints gerenciados e nunca fixar IPs.

No Aurora, a alta disponibilidade e a escala de leitura são faces da mesma moeda: os readers servem tráfego em regime normal e o melhor deles é promovido a writer em caso de falha, com failover que em muitos casos fica abaixo dos 30 segundos. O Aurora PostgreSQL e o Aurora MySQL também suportam réplicas cross-region com o mesmo papel de plano B regional discutido no arquivo anterior. A regra de decisão continua válida: RDS tradicional com Multi-AZ cobre a maioria das cargas com previsibilidade de custo; Aurora entra quando o failover precisa ser mais rápido, a leitura precisa de muitos readers ou o lag precisa ser mínimo.

Multi-AZ DB Cluster

O Multi-AZ DB Cluster é a evolução do esquema para cargas que exigem failover mais rápido e capacidade de leitura no standby. A implantação mantém um writer e dois standbys, ambos legíveis, em três zonas de disponibilidade, com replicação semissíncrona: o writer aguarda confirmação de escrita de um standby antes de confirmar a transação ao cliente. A aplicação enxerga dois endpoints: o writer endpoint, que sempre aponta ao primário, e o reader endpoint, que distribui leituras entre os standbys.

O ganho duplo é claro: failover abaixo dos 35 segundos típicos, porque os standbys já processam leituras e mantêm buffers quentes, e escala de leitura sem alterar o desenho de endpoints, pois o reader endpoint roteia automaticamente. O custo é maior que o Multi-AZ clássico, pois são duas instâncias adicionais, e o standby do DB Cluster introduz a noção de leitura levemente defasada, herdando as preocupações de consistência já discutidas no arquivo de réplica de leitura.

A migração entre os dois esquemas é online: uma instância Multi-AZ DB Instance pode ser convertida em Multi-AZ DB Cluster com um comando de modificação, e o caminho inverso também existe. A escolha depende de três perguntas diretas: o SLO de indisponibilidade tolera 60 a 120 segundos, a leitura precisa dos standbys e o orçamento comporta três instâncias. Respostas negativas às duas primeiras apontam para o esquema clássico; respostas positivas nas duas últimas justificam o cluster.

Teste de failover

Um mecanismo de failover só é confiável se testado; o RDS fornece a alavanca oficial com o reboot com failover, que simula a falha do primário e força a troca de papel sob carga real da aplicação. O teste valida três coisas que documentação não valida: o comportamento do driver e do pool de conexões diante da queda, o tempo efetivo de recuperação percebido pelo usuário e a corretude dos alarmes e dashboards do time de plantão.

• Ensaiar o reboot com failover em ambiente de staging com tráfego sintético, medindo erros vistos pela aplicação e latência de recuperação.
• Repetir o teste em produção em janela de baixo tráfego, com plantão completo e rollback documentado, pois o procedimento é seguro e oficialmente suportado.
• Verificar após o teste a alocação de zonas: primário e standby devem voltar a ocupar zonas distintas, requisitando realocação quando necessário.
• Registrar o RTO medido e comparar com a meta de SLO do serviço; desvios sistemáticos indicam problemas de pool de conexão ou de DNS na aplicação.
• Automatizar o teste no calendário trimestral do time, pois procedimento que só existe em documentação tende a falhar exatamente na primeira execução real.

Aplicação prática: comportamento do cliente

O contrato de Multi-AZ impõe disciplina do lado da aplicação. Conexões ativas caem no failover, pois a troca de papel encerra as sessões do primário antigo; o driver precisa reconectar e o pool precisa validar conexões antes de reutilizá-las. Aplicações que fixam IP em vez de usar o endpoint DNS quebram o mecanismo por completo, pois a troca acontece no DNS.

# Pseudocódigo de tratamento de falha transiente durante failover
import time, socket

def executar_com_retry(operacao, tentativas=4):
    for i in range(tentativas):
        try:
            return operacao()
        except (OperationalError, socket.timeout):
            # erro típico de conexão derrubada pelo failover
            espera = 0.5 * (2 ** i)          # backoff exponencial: 0.5, 1, 2, 4 s
            time.sleep(espera)
    raise RuntimeError("banco indisponível após failover")

Boas práticas de configuração incluem: usar sempre o endpoint gerenciado, manter TTL curto no resolver interno para absorver a troca de DNS, configurar retry de leitura com segurança de idempotência e preferir transações curtas, que reduzem o número de sessões presas no primário no instante da troca.

Erros comuns e boas práticas

• Erro: confundir Multi-AZ com escala de leitura e aguardar alívio de CPU no primário; o standby não atende consultas; prática: read replica para leitura, Multi-AZ para disponibilidade.
• Erro: apontar aplicações por IP ou por CNAME próprio com TTL alto, impedindo a troca de DNS; prática: endpoint do RDS sempre, com resolver respeitando TTL.
• Erro: nunca testar o failover e descobrir na crise que o pool de conexões não recupera; prática: reboot com failover periódico, instrumentado e medido.
• Erro: assumir RPO zero absoluto para qualquer operação; transações em voo não confirmadas não são garantidas; prática: idempotência nas operações de escrita e retry com backoff.
• Erro: desprezar o custo dobrado de instância e storage do standby no orçamento; prática: incluir Multi-AZ no TCO desde o desenho e avaliar Aurora quando a conta crescer.
• Erro: manter transações longas em produção; no failover elas são encerradas e o trabalho é perdido; prática: transações curtas, jobs longos com checkpoint e retomada.

Como síntese técnica, Multi-AZ entrega alta disponibilidade com RTO medido em segundos e RPO zero para transações confirmadas, ao custo de uma instância que fica ociosa em regime normal. Essa ociosidade é o preço da simplicidade operacional: nenhum runbook, nenhuma decisão sob pressão, nenhuma divergência de dados. O desenho maduro trata Multi-AZ como linha de base e adiciona réplicas de leitura como camada independente de escala.