AWS Read Replica (Replicas de Leitura)

As read replicas são cópias assíncronas de uma instância RDS destinadas a distribuir leitura e a servir regiões distantes sem saturar o banco primário. Em produção, a técnica é uma das alavancas mais eficazes de escala relacional: enquanto o caminho de escrita continua concentrado em uma única instância, o caminho de leitura, que domina a maior parte das cargas de aplicação web, escala horizontalmente com réplicas adicionais. O Amazon RDS gerencia a replicação, o failover de réplica e a promoção, mas o desenho do roteamento de consultas continua sendo responsabilidade da aplicação, e é nesse ponto que a maioria das implementações erra. A diferença conceitual com o Multi-AZ é essencial: Multi-AZ é alta disponibilidade com standby invisível, réplica de leitura é escala e distribuição com instância acessível para consultas. Este arquivo cobre o funcionamento interno, os limites por engine, a promoção, a replicação cross-region, a métrica de atraso e o custo real de cada réplica.

Funcionamento interno da replicação

A replicação de read replica no RDS é assíncrona e se apoia nos mecanismos nativos de cada engine: o PostgreSQL usa slots de replicação e shipping de WAL, o MySQL usa binlog com threads de I/O e SQL na réplica. A instância primária envia alterações contínuas, e a réplica as aplica em streaming, mantendo um atraso tipicamente na casa de milissegundos a poucos segundos quando a carga está saudável.

Por ser assíncrona, a réplica não garante a mesma visão de dados do primário em um instante dado: uma escrita confirmada no primário pode levar um instante para aparecer na réplica. Esse atraso é aceitável para leitura de catálogo, histórico e relatórios, e inaceitável para fluxos como leitura imediatamente após escrita no mesmo request, que precisam ir ao primário ou ser redesenhados. O RDS monitora a saúde da replicação e encerra réplicas persistentemente atrasadas além do limite de tolerância, o que exige alarme e resposta operacional.

A replicação em cascata amplia o modelo: uma réplica pode ser fonte de outra réplica, o que é útil para distribuir leitura sem multiplicar a carga de exportação de log no primário, com a ressalva de que o atraso se soma ao longo da cadeia e o monitoramento deve cobrir cada elo.

Limites e comportamento por engine

O Aurora merece atenção na comparação: como o cluster compartilha o volume de storage, a réplica aurora tem atraso tipicamente menor que a replicação binlog do RDS clássico, e o leitor pode ativar cache de query plan e endpoint de leitura gerenciado. Para o RDS clássico, cada réplica é uma instância completa com storage próprio, e o tamanho da instância e do storage influenciam diretamente o atraso.

Promoção a instância independente

Toda read replica pode ser promovida a instância autônoma, rompendo o vínculo de replicação de forma permanente. A promoção é o caminho oficial de migração de banco entre regiões, de separação de um serviço monolítico em banco dedicado e de recuperação de desastre quando a réplica cross-region assume o papel de primário em outra região.

A operação tem consequências que precisam entrar no runbook. A promoção induz indisponibilidade de poucos minutos enquanto a réplica aplica o backlog e reinicia; registros de replicação são descartados, e não há caminho de volta sem recriar a replicação a partir de snapshot; endpoints e strings de conexão da aplicação precisam ser atualizados. Em plano de desastre, o desenho típico é réplica cross-region em modo passivo, com promoção ensaiada e automatizada por pipeline, e DNS ou Route 53 redirecionando a aplicação para o novo primário.

Réplicas cross-region

O RDS permite réplicas em regiões distintas da primária, servindo leitura regional com latência local e oferecendo réplica quente para desastre. A replicação atravessa a WAN entre regiões, com atraso proporcional à distância e à taxa de escrita do primário; cargas com volume de escrita alto merecem medição real antes de comprometer SLA de leitura local.

O caso de uso mais forte é a aplicação multi-região de leitura: usuários na Europa consultam a réplica europeia, enquanto escritas persistem no primário da região principal. O segundo caso é continuidade de negócio, com a réplica cross-region como RTO reduzido: em desastre regional, promove-se a réplica e redireciona-se o tráfego. Em ambos, criptografia em trânsito entre regiões e consideração de residência de dados fazem parte do desenho, não são opcionais.

A criação da réplica cross-region parte de um snapshot da primária, e o atraso inicial até a convergência depende do volume de escrita acumulado; planeje a ativação fora de picos e valide a métrica de atraso antes de direcionar leitura regional.

ReplicaLag como métrica central

A métrica ReplicaLag no CloudWatch mede, em segundos, o atraso da réplica em relação ao primário, e é a métrica de alarme obrigatória de qualquer arquitetura com réplicas. Atraso crescente indica que a réplica não acompanha a taxa de escrita, tipicamente por subdimensionamento da réplica, por consultas pesadas rodando nela ou por saturação de rede.

# Alarme de atraso da réplica acima de 5 segundos por 10 minutos
aws cloudwatch put-metric-alarm \
  --alarm-name rds-replica-lag-alto \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=prod-pedidos-replica-01 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:sa-east-1:123456789012:dba-oncall

O comportamento da aplicação diante de atraso também deve ser deliberado: tolerar leitura defasada em rotas não críticas, redirecionar rotas sensíveis ao primário e, em casos de atraso extremo, degradar funcionalidades com mensagens explícitas, em vez de propagar dados inconsistentes silenciosamente.

Roteamento na aplicação

O roteamento de consultas é a parte que nenhum serviço AWS resolve pela aplicação: a conexão à réplica é uma conexão comum ao endpoint da réplica, e decidir o que vai onde é decisão de arquitetura de aplicação. O padrão robusto separa conexões no nível do pool de conexões, com datasource de escrita e datasource de leitura configurados explicitamente.

// Roteamento por tipo de operação com dois datasources
@Bean
@Primary
public DataSource writeDataSource() {
    // Primário: escrita e leituras que exigem consistência imediata
    return buildPool("prod-pedidos.c8xyz.sa-east-1.rds.amazonaws.com", 20);
}

@Bean
public DataSource readDataSource() {
    // Réplica: consultas de listagem, relatórios e telas de consulta
    return buildPool("prod-pedidos-replica-01.c8xyz.sa-east-1.rds.amazonaws.com", 40);
}

Padrões consolidados enviam para a réplica consultas de listagem, telas de consulta, feeds, agregações e relatórios; e mantêm no primário fluxos de leitura-apos-escrita, validações de unicidade crítica, transações e operações administrativas. Em frameworks ORM, anotações ou aspectos por método formalizam a decisão, e revisão de código impede que consultas sensíveis escorreguem para a réplica sem avaliação.

Quando o roteamento manual se torna pesado, ferramentas de proxy de banco, como PgBouncer em frente a múltiplos endpoints ou sharding proxies, podem centralizar a decisão, mas a maioria dos sistemas resolve bem com dois pools explícitos e convenções revisadas em code review.

Aplicação prática: relatórios e leitura regional

O caso clássico de produção é o isolamento de relatórios: consultas analíticas pesadas consomem a réplica, e o primário segue dedicado ao transacional com latência estável. O segundo caso é a leitura regional: uma réplica por região de usuário reduz latência percebida em dezenas de milissegundos por consulta, um ganho multiplicado em páginas com muitas consultas.

Quando a carga analítica cresce de relatórios pontuais para análises contínuas e pesadas, a resposta correta deixa de ser réplica e passa a ser pipeline para um warehouse ou para DynamoDB de consulta, com a réplica voltando ao papel de leitura transacional.

Read Replica versus Multi-AZ

Arquiteturas de produção sérias combinam os dois: Multi-AZ no primário para disponibilidade, réplicas para escala de leitura e, quando há exigência de continuidade regional, réplica cross-region ensaiada para promoção.

Custo de cada réplica

Cada réplica é cobrada como uma instância completa: mesma classe de instância ou menor, storage próprio ou compartilhado conforme engine, IOPS de disco e transferência de dados entre regiões no caso cross-region. O custo escala linearmente com o número de réplicas, e a conta de leitura cresce mais rápido que a de aplicação quando réplicas são provisionadas por conveniência e não por demanda medida.

A disciplina de produção é simples: provisione réplicas com base em utilização medida, preferindo réplicas menores múltiplas a uma réplica gigante ociosa, aplique autoscaling de réplicas quando o padrão de tráfego permitir, e revise réplicas sem uso em revisões mensais de custo. Réplica de classe alta rodando com 5% de CPU é o achado mais comum de FinOps em ambientes com RDS.

Erros comuns e boas práticas

• Redirecionar todo o tráfego de leitura para a réplica e quebrar fluxos de leitura-apos-escrita; classifique consultas por exigência de consistência antes de rotear.
• Ignorar o alarme de ReplicaLag e descobrir dados defasados por reclamação de usuário; alarme e política de resposta vêm primeiro.
• Usar a réplica para consultas analíticas contínuas pesadas, saturando o caminho de leitura transacional; nesse ponto o caminho é warehouse.
• Provisionar réplica da mesma classe gigante do primário por inércia; dimensione pela carga de leitura real da réplica.
• Esquecer a conta de transferência entre regiões em réplicas cross-region; estime com a taxa de escrita medida.
• Tratar a promoção de réplica como operação improvisada; ensaie o runbook de desastre com data, execução e validação.
• Conectar ferramentas de BI diretamente ao primário; aponte-as para a réplica com usuário dedicado de leitura.
• Deixar réplicas antigas de migrações concluídas rodando sem dono; inventarie réplicas com responsável e finalidade.
• Aplicar consultas com leitura de estado recém-escrito na réplica e depurar inconsistências como bug de banco; o problema é de roteamento.

Como prática consolidada, trate cada réplica como parte do SLA de leitura: defina atraso máximo aceitável por tipo de consulta, alarme com resposta de plantão, roteamento explícito e testado, e revisão periódica de custo e utilização. A réplica certa na carga certa entrega escala de leitura com previsibilidade; a réplica errada entrega o mesmo custo com risco de consistência.