Write Ahead {B}Log

Quem trabalha com banco de dados em produção conhece bem a sensação. O sistema está no ar, os gráficos estão verdes, o SLA está sendo cumprido. Ainda assim, existe sempre aquele desconforto silencioso: “se algo grave acontecer agora, a gente realmente sabe o que fazer?”

Planos de Disaster Recovery, diagramas e documentações existem. O problema é que, na prática, quando uma falha acontece, o que define o sucesso da recuperação não é o que está escrito no papel, mas a confiança operacional do time. Em geral, essa confiança só aparece quando o plano foi pensado, testado e refinado com base em cenários reais.

Foi exatamente para atacar esse tipo de lacuna que a AWS criou o Resilience Analysis Framework. Ele não é uma lista de serviços para marcar como implementada, mas um método estruturado para analisar riscos, impacto e resposta.

Neste artigo, vou aplicar o framework especificamente ao contexto de bancos de dados na AWS, conectando os conceitos com exemplos reais de alta disponibilidade (HA) e disaster recovery (DR), e trazendo o olhar de quem vive operação, plantão e pós-mortem.

Antes de tudo: o que realmente significa resiliência?

Resiliência, no contexto técnico, não é apenas “não cair”. Segundo o framework da AWS, resiliência é a capacidade de um workload resistir, absorver, se recuperar e continuar operando diante de falhas, sejam elas técnicas, humanas ou externas.

Isso se apoia em dois pilares que muita gente mistura, mas que precisam ser tratados separadamente: Availability e Disaster Recovery.

Disponibilidade é uma métrica que olha para o passado. Ela responde à pergunta: quanto tempo meu banco esteve disponível ao longo de um período? É aqui que entram os famosos “cinco noves”, Multi-AZ, réplicas, health checks e failover automático.

Disaster Recovery, por outro lado, trata do momento após alguma falha acontecer. Aqui entram duas métricas fundamentais que todo administrador de banco de dados deveria saber explicar sem consultar: RTO e RPO.

RTO, ou Recovery Time Objective, é o tempo máximo aceitável para o serviço voltar ao ar depois de um incidente. Se o seu RTO é 15 minutos, qualquer recuperação que leve mais do que isso já é, tecnicamente, uma falha.

RPO, ou Recovery Point Objective, é o quanto de dados você pode perder. Um RPO de zero significa que você não aceita perder nenhuma transação confirmada. Um RPO de 5 minutos significa que, no pior cenário, você aceita voltar o banco para um estado de até 5 minutos atrás.

Esses conceitos parecem simples, mas na prática é exatamente onde muitos ambientes quebram, porque nunca foram validados contra falhas reais.

O Resilience Analysis Framework como lente para bancos de dados

O grande valor do Resilience Analysis Framework é que, ao aplicar o framework a bancos de dados, cinco perguntas surgem de forma quase natural, e elas servem como um fio condutor para analisar qualquer arquitetura na AWS.

Vamos passar por essas perguntas usando exemplos reais de bancos relacionais na nuvem.

E se meu nó de banco falhar?

Esse é o cenário mais básico e, paradoxalmente, onde muita gente ainda erra. Em um banco tradicional rodando em uma única instância, seja on-premises, EC2 ou até um RDS Single-AZ, a falha do nó significa indisponibilidade total. O storage, o processo do banco e as conexões caem juntos. O RTO costuma ser alto e o RPO depende da última cópia de backup.

Já quando você adota Aurora PostgreSQL ou MySQL com Multi-AZ, a história muda bastante. O storage é distribuído em três zonas de disponibilidade, com seis cópias síncronas dos dados. Isso garante RPO zero para falhas de instância ou de uma AZ inteira. O failover do writer costuma acontecer em alguns segundos, o que reduz drasticamente o RTO.

Mas aqui entra um ponto que o framework deixa claro: ter o mecanismo de recuperação estabelecido e documentado não significa que ele funciona bem para o seu workload. Se a aplicação não reconecta corretamente, se o pool de conexões não lida bem com falha, ou se o DNS cache do cliente é agressivo demais, aquele failover “automático” vira um incidente prolongado.

A pergunta que o framework força o DBA a responder não é “tenho réplica?”, mas sim: o que acontece do ponto de vista da aplicação quando esse nó cai? Quantas conexões quebram? Quanto tempo até o tráfego estabilizar de novo?

E se eu precisar absorver picos imprevisíveis de carga?

Falhas nem sempre vêm na forma de indisponibilidade total. Muitas vezes, o sistema “fica de pé”, mas responde tão mal que, para o usuário, está fora do ar.

Em bancos tradicionais, escalar quase sempre significa escolher entre duas dores: escalar verticalmente (instância maior) ou escalar leitura com réplicas. Ambas têm limites claros. O writer continua sendo um gargalo, e o número de conexões vira um problema antes mesmo da CPU.

Aqui, o framework ajuda a identificar um risco que costuma ser subestimado: exaustão de recursos operacionais, não de dados. Pool de conexões saturado, limite de sessões, lock contention, cache frio após restart.

Aurora ajuda bastante ao separar compute e storage e permitir múltiplas réplicas de leitura. Mas ainda exige decisões: quantas réplicas? de que tamanho? quem pode ler delas? o que acontece quando o writer está sob pressão?

O framework propõe tratar essas questões como risco de resiliência: o que acontece com a disponibilidade quando o desempenho degrada?

E se uma região inteira falhar?

Esse é o cenário que muita gente evita discutir porque “é raro”. Até o dia em que acontece.

Falha regional não é apenas queda total. Pode ser uma indisponibilidade de rede, um problema de controle, ou até um evento externo que isole a região. Quando isso acontece, não adianta ter o melhor Multi-AZ do mundo, pois AZs não ajudam se a região inteira estiver comprometida.

O Aurora Global Database resolve parte desse problema ao manter uma réplica física em outra região, com RPO tipicamente em torno de segundos. Para muitos negócios, isso é suficiente. Para outros, qualquer perda de dados já é inaceitável.

Aqui o framework força uma pergunta essencial: meu RPO zero precisa ser local ou global? E mais importante: meu time sabe executar um failover regional sem pânico?

Muitos ambientes têm Global Database configurado, mas nunca testaram um switchover real. Quando chega o momento, o medo de perder dados ou de não conseguir voltar impede a ação rápida e o RTO explode.

Como eu gerencio conexões sem virar refém de writer, replica lag e DNS?

Writer endpoint, reader endpoint, custom endpoints, proxies, pools externos, timeouts, retries. Tudo isso existe para esconder da aplicação a complexidade do banco. Mas, quando algo falha, essas camadas extras podem se tornar o próprio problema.

O Resilience Analysis Framework trata isso como dependência crítica. Se a sua estratégia de HA depende de DNS rápido, mas seus clientes cacheiam DNS por minutos, você tem um risco claro. Se depende de proxies externos que também podem falhar, isso aumenta o blast radius. Em arquiteturas resilientes, o objetivo não é apenas evitar falhas, mas também conter o impacto quando elas acontecem.

A pergunta aqui não é “qual endpoint usar?”, mas sim: o que precisa estar saudável para que a aplicação consiga se reconectar automaticamente? E quantas dessas coisas eu controlo de verdade?

Esse tipo de reflexão muda completamente como você avalia drivers, proxies e padrões de conexão.

Como eu faço manutenção e upgrades sem trauma?

Poucos incidentes são tão evitáveis quanto aqueles causados por manutenção mal planejada.

Upgrade de engine, patch de sistema operacional, mudança de parâmetro, rebuild de índice. Tudo isso afeta disponibilidade, performance e, muitas vezes, a confiança do negócio.

Aurora ajuda muito com upgrades gerenciados, rolling updates, blue/green e clones rápidos. Mas, novamente, o framework puxa a conversa para um nível mais profundo: o que acontece com a performance depois do restart? Quanto tempo leva para o cache aquecer? Meu RTO considera isso ou só o “serviço no ar”? Resiliência não é só voltar rápido, mas voltar com performance.

Diretrizes do Resilience Analysis Framework aplicadas a bancos de dados

Se fosse preciso condensar todo o Resilience Analysis Framework em um playbook prático para quem cuida de bancos de dados na AWS, ele poderia ser resumido em algumas diretrizes fundamentais.

1. Defina RTO e RPO antes de escolher tecnologia. Não existe arquitetura correta sem entender o impacto do downtime e da perda de dados no negócio. Multi-AZ, replicas, global database ou multi-region só fazem sentido quando conectados a objetivos claros de recuperação.
2. Trate disponibilidade e disaster recovery como problemas diferentes. Alta disponibilidade reduz incidentes, mas não substitui disaster recovery. Um banco pode ser altamente disponível dentro de uma região e ainda assim falhar completamente diante de um evento regional.
3. Elimine os pontos únicos de decisão e recuperação. Writer único, failover manual, scripts que só uma pessoa conhece ou decisões que dependem de intervenção humana aumentam o RTO mais do que qualquer limitação técnica.
4. Conexões fazem parte da resiliência. Pooling, endpoints, DNS, proxies e drivers precisam ser pensados como componentes críticos. Um banco pode se recuperar rapidamente e ainda assim parecer “fora do ar” se a aplicação não souber reconectar corretamente.
5. Falhas parciais são mais perigosas do que falhas totais. Latência alta, replica lag, degradação silenciosa e saturação de conexões causam mais dano ao longo do tempo do que um corte claro e detectável.
6. Teste continuamente em condições reais. Disaster Recovery que só existe no papel ou que é testado uma vez por ano não gera confiança. Ambientes secundários precisam receber tráfego real, mesmo que parcial, para que problemas apareçam antes do desastre.
7. Observabilidade não é opcional. Métricas, logs e traces precisam responder rapidamente a perguntas simples: o banco está disponível, consistente e performando bem? Sem isso, decisões de failover se tornam apenas apostas.
8. Resiliência é uma propriedade do sistema, não um evento isolado. Se cada falha vira uma operação de guerra, algo está errado. O objetivo é que o banco continue funcionando enquanto partes dele falham e se recuperam.

Erros comuns ao pensar resiliência em BD

1. “Multi-AZ é meu DR”. Esse é provavelmente o equívoco mais comum em arquiteturas na AWS. Configurar um banco em Multi-AZ melhora muito a disponibilidade contra falhas de instância, host ou até de uma zona inteira. Mas isso não é disaster recovery. A pergunta que precisa ser feita: “Se essa região inteira ficar indisponível agora, quanto tempo levamos para voltar e com quantos dados perdidos?”. Se a resposta não existe, então o DR também não existe.
2. RTO e RPO definidos “no feeling”. Definir RTO e RPO sem ligação real com o impacto no negócio e sem contexto levam a arquiteturas superdimensionadas ou perigosamente frágeis. Um sistema financeiro pode exigir RPO zero. Um sistema interno pode tolerar horas de perda. O problema não é escolher um valor alto ou baixo. O problema é não escolher conscientemente.
3. DR que existe, mas nunca foi testado. Talvez o mais perigoso de todos. O ambiente secundário está lá, a réplica existe, os backups rodam. Mas ninguém nunca promoveu a réplica em produção, validou a aplicação conectando nela e mediu o tempo real de recuperação. No framework, isso quebra o princípio mais básico: resiliência que não é testada é apenas assumida.
4. “O banco voltou, mas a aplicação não”. Resiliência não termina no banco. Conexões quebradas, pools travados, DNS cacheado, ausência de retry, timeouts mal configurados, tudo isso derruba o sistema mesmo com o banco saudável. O framework deixa claro que recuperação envolve todo o workload, não apenas o componente de dados. Ignorar isso é transformar HA em meia solução.
5. A réplica existe, mas nunca é usada. Ela não recebe tráfego real, não é monitorada como o primário e não é validada em performance. Quando chega o dia do failover, surgem surpresas: permissões quebradas, schema defasado, latência inesperada. O framework recomenda active redundancy sempre que possível. Ambientes secundários precisam rodar, não apenas existir.
6. DR baseado apenas em backup. Backup é essencial, mas backup sozinho não é estratégia de recuperação rápida. Restaurar backup costuma significar horas de indisponibilidade, validações manuais e muita pressão operacional. Isso pode ser aceitável, desde que seja uma escolha consciente e alinhada ao RTO definido.
7. Observabilidade só depois do incidente. Sem métricas claras, ninguém sabe quando a falha começou, se a réplica está atrasada ou se o failover terminou. Observabilidade não é luxo nem “nice to have”. Ela é o que permite decidir rápido quando tudo está dando errado. No framework, ela sustenta todos os pilares da resiliência.

Então, como escolher a estratégia certa?

Não existe uma única resposta correta para HA e DR em bancos de dados na AWS. Existe a resposta adequada ao risco, ao impacto e à maturidade operacional do time.

Por exemplo, Aurora PostgreSQL e MySQL são excelentes escolhas quando você precisa de compatibilidade total, controle fino e padrões bem conhecidos, com Multi-AZ e, se necessário, Global Database.

Outras abordagens (como Aurora DSQL) podem fazer mais sentido quando o problema não é apenas disponibilidade, mas complexidade operacional, escala imprevisível e dificuldade de testar failover sem medo.

O Resilience Analysis Framework não existe para escolher tecnologias por você. O valor real dele está em algo mais importante: forçar decisões conscientes, baseadas em riscos reais, impacto no negócio e comportamento em falhas.

Conclusão: resiliência não é apenas arquitetura, é prática

Para equipes de bancos de dados, talvez a maior lição seja esta: resiliência não nasce no diagrama de arquitetura ou na documentação estratégica, nasce no treino. O melhor design do mundo falha se o time não confia nele. E confiança só vem quando os cenários foram pensados, testados e ajustados.

Aplicar o Resilience Analysis Framework a bancos de dados na AWS é menos sobre aprender algo novo e mais sobre organizar o que já sabemos, de forma honesta e pragmática. É transformar HA e DR para além de um discurso, uma capacidade real do sistema e principalmente do time.

No fim, não se trata de evitar falhas. Falhas são inevitáveis. Trata-se de garantir que, quando elas acontecerem, o banco e o time estejam prontos.

Referências

https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html