AWS RDS Read Replica (Conceito)

O read replica do Amazon RDS é uma cópia somente leitura de uma instância de banco de dados gerenciada, criada e mantida pelo serviço a partir da replicação nativa do motor escolhido. A operação de criação é essencialmente de um clique no console ou de um comando único na CLI, sem backup manual, sem pg_basebackup, sem configuração de pg_hba.conf; o RDS provisiona a instância, executa o snapshot de origem e conecta o stream de replicação. O PostgreSQL e o MySQL no RDS suportam até 15 réplicas de leitura por instância de origem, e o Aurora segue o mesmo teto com seus Aurora Replicas. Cada réplica recebe seu próprio endpoint DNS, permitindo direcionar aplicações e ferramentas de análise a nós específicos. Em produção, esse recurso é a resposta padrão da AWS para escala de leitura, isolamento de relatórios e preparação de recuperação de desastres, com toda a operação de replicação sob responsabilidade do provedor.

Conceito e posicionamento no RDS

A read replica é uma instância completa do RDS, com classe própria, armazenamento próprio, parâmetros próprios e faturação própria; o que a distingue é o papel: ela aplica continuamente as alterações da origem e rejeita escritas. A origem pode ser qualquer instância primária ou, em cadeias suportadas, outra réplica, formando topologias em cascata que economizam largura de banda no primário. A replicação é assíncrona, o que significa que toda réplica do RDS opera com alguma defasagem, normalmente na casa de centenas de milissegundos.

Esse desenho segue a divisão de papéis do arquivo anterior deste módulo: escrita no primário, leitura nas réplicas, com monitoramento do lag como condição de uso. A diferença operacional é quem administra o mecanismo. No banco auto-hospedado o time configura WAL, binlog, autenticação e monitoramento; no RDS o serviço cuida dessas camadas e expõe apenas os comandos de criação, modificação, promoção e exclusão, além das métricas de observação.

O problema que resolve

O gargalo clássico em produção é o primário que atende simultaneamente o caminho transacional, o time de BI, o serviço de busca e o job de relatório mensal. Adicionar CPU à instância resolve parcialmente, com custo não linear e teto de classe; mover leituras para réplicas resolve com custo linear e isolamento por perfil. O RDS reduz a barreira de entrada dessa solução de horas ou dias, no banco auto-hospedado, para minutos, no serviço gerenciado.

O segundo problema resolvido é o de recuperação de desastres regional. Uma réplica cross-region mantém uma cópia atualizada em outra região da AWS, e a promoção dela em caso de desastre da região primária é um único comando, muito mais rápido que restaurar snapshots sobre infraestrutura reconstruída. O terceiro é a migração e o reescalonamento estrutural: promover uma réplica a primário é caminho legítimo para mover um banco para outra região, outra VPC ou outra classe sem dump e restore completos.

Criação e ciclo de vida

O ciclo de vida completo é criação, uso, monitoramento e eventual promoção ou exclusão. Na criação, o RDS tira um snapshot da origem, restaura em nova instância, conecta o stream de replicação e coloca o endpoint no ar; o tempo total varia com o tamanho do banco, de minutos a horas. A partir daí a réplica se mantém sozinha, aplicando as alterações recebidas.

# Criação de uma réplica de leitura na mesma região, com classe dedicada
aws rds create-db-instance-read-replica \
  --db-instance-identifier vendas-replica-01 \
  --source-db-instance-identifier vendas-prod \
  --db-instance-class db.r6g.xlarge \
  --availability-zone us-east-1b

# Réplica cross-region: a origem é informada pelo ARN e a região é a de destino
aws rds create-db-instance-read-replica \
  --db-instance-identifier vendas-replica-euw1 \
  --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:vendas-prod \
  --db-instance-class db.r6g.xlarge \
  --region eu-west-1

Cada réplica tem endpoint próprio no formato identificador.assinatura.região.rds.amazonaws.com, e o custo é o de instância mais armazenamento, como qualquer RDS; tráfego de replicação dentro da mesma região é gratuito, entre regiões é cobrado por GB transferido. Réplicas podem ser modificadas independentemente, inclusive receber Multi-AZ próprio, e podem ser promovidas ou excluídas sem afetar as irmãs.

Como a replicação funciona por motor

O RDS usa o mecanismo nativo de cada banco, e conhecer o mecanismo evita expectativas erradas. No MySQL e no MariaDB, a replicação é assíncrona baseada em binlog, com métrica de defasagem publicada como ReplicaLag; transações grandes atrasam a cadeia inteira. No PostgreSQL, a replicação é o streaming físico do WAL, e o lag aparece como distância de replay; DDL e vacuum da origem são reproduzidos integralmente na réplica.

A diferença do Aurora merece destaque: nos motores clássicos do RDS cada réplica é uma cópia completa dos dados aplicando log; no Aurora as réplicas leem o mesmo volume distribuído do cluster, o que elimina o custo de armazenamento por réplica e reduz drasticamente o lag. Para cargas de leitura intensiva, essa é a principal razão técnica de migração do RDS para o Aurora.

Promoção a primário

A promoção transforma a réplica em instância primária independente: o stream de replicação é encerrado, a instância passa a aceitar escritas e não há caminho de volta para o papel anterior sem reconstrução. A operação leva poucos minutos, pois os dados já estão na réplica, e o ponto crítico é o redirecionamento das aplicações para o novo endpoint, tarefa que cabe à operação.

# Promove a réplica a instância primária independente
aws rds promote-read-replica --db-instance-identifier vendas-replica-01

# Variante cross-region, executada na região da réplica
aws rds promote-read-replica \
  --db-instance-identifier vendas-replica-euw1 \
  --region eu-west-1

Os usos consolidados da promoção são três. Primeiro, recuperação de desastres: se a região de origem cai, a réplica cross-region promovida assume o tráfego global. Segundo, migrações estruturais: mover um banco para outra região ou VPC promovendo a réplica criada lá. Terceiro, fragmentação orgânica: um inquilino gigante pode ser "fatiado" promovendo uma réplica dedicada, que se torna o primário dele. Em todos os casos o alerta é o mesmo: após a promoção as cópias divergem definitivamente.

Réplicas cross-region em detalhe

A réplica cross-region reproduz o fluxo de replicação através da backbone da AWS para outra região, usando o ARN da origem como identificador. O caso de uso central é recuperação de desastres regional: se a região de origem ficar indisponível, a réplica promovida assume o tráfego global com minutos de atraso, muito abaixo do tempo de restaurar snapshots em infraestrutura reconstruída manualmente. O segundo caso é latência: empresas com usuários na Europa e no Brasil mantêm réplicas regionais para servir consultas locais com caminho de rede curto.

Os custos e limites mudam em relação à réplica local. A transferência de dados de replicação entre regiões é cobrada por GB, e o volume depende do churn do banco; cargas com muitos UPDATEs e vacuum pesado geram mais tráfego. O lag cresce com a distância física e com a instabilidade da rede entre regiões, tipicamente na faixa de um a poucos segundos, e o alarme de lag deve ter limiar mais folgado que o da réplica local. Por fim, a promoção cross-region é uma decisão de negócio, pois após ela as duas cópias divergem e a reconvergência exige reconstrução da topologia.

Casos de uso em produção

• Escala de leitura transacional: endpoints de réplica no pool de leitura da aplicação para listagens, consultas de catálogo e leituras de sessão.
• Relatórios e BI: ferramentas analíticas apontadas para uma réplica dedicada, com classe dimensionada para consultas longas e sem impacto no primário.
• Leitura regional: réplica cross-region em áreas geográficas com usuários concentrados, reduzindo latência de rede das consultas.
• Backup consistente: dumps executados sobre a réplica, evitando pressão de I/O no primário em horário comercial.
• Recuperação de desastres: réplica cross-region como plano B regional, com promoção ensaiada periodicamente.
• Migrações: réplica como alvo de transição para trocar região, VPC, classe ou conta AWS com janela mínima de indisponibilidade.

Comparação com Aurora e Multi-AZ

A escolha entre os três arranjos confunde times, pois todos envolvem a palavra réplica; o separador é o objetivo de cada um.

A regra de decisão prática: Multi-AZ é presença padrão em qualquer banco de produção sério por causa do failover; réplicas de leitura entram quando a leitura satura; Aurora entra quando o lag precisa ser mínimo ou quando a contagem de readers cresce, porque o storage único muda a economia da topologia.

Monitoramento do lag e alarmes

A métrica ReplicaLag no CloudWatch mede a defasagem em segundos e é a base de três decisões operacionais: remover a réplica do pool de leitura, investigar consultas longas na réplica e ajustar a classe da instância. Em Aurora a métrica equivalente é AuroraReplicaLag, medida em milissegundos. Alarmes com limiar realista, por exemplo 5 segundos contínuos em RDS ou 100 ms em Aurora, capturam degradação antes que o usuário perceba.

# Alarme de lag: dispara se a réplica ficar mais de 5 segundos defasada
aws cloudwatch put-metric-alarm \
  --alarm-name rds-vendas-replica01-lag \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=vendas-replica-01 \
  --statistic Average \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:dba-alertas

# Inspeção rápida do lag atual da réplica
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=vendas-replica-01 \
  --start-time 2025-01-15T12:00:00Z --end-time 2025-01-15T13:00:00Z \
  --period 300 --statistic Maximum

Erros comuns e boas práticas

• Erro: tratar a réplica como forte e consistente a todo momento; a replicação é assíncrona e o lag existe por definição; prática: roteamento consciente do lag e leitura pós-escrita no primário.
• Erro: usar a réplica promovida esperando que o primário original continue sincronizado ao contrário; promoção corta o vínculo definitivamente; prática: planejar a topologia final antes de promover.
• Erro: dimensionar réplica de relatórios com a mesma classe do primário e reclamar do custo, ou pior, com classe minúscula e receber lag de horas; prática: classe por perfil de consulta e alarme em ReplicaLag.
• Erro: esquecer que réplica cross-region gera custo de transferência de dados contínuo; prática: estimar GB por dia de WAL e binlog no orçamento do FinOps.
• Erro: apontar aplicações para IPs e não para os endpoints DNS do RDS; prática: sempre endpoints, pois IPs mudam em manutenção e failover.
• Erro: criar cadeias de réplica profundas sem necessidade, somando lag de cada elo; prática: replicar direto da origem quando a largura de banda permitir.

Como fechamento técnico, o read replica do RDS é a porta de entrada para escala de leitura gerenciada: baixa fricção de criação, teto de 15 réplicas para PostgreSQL e MySQL, promoção como caminho de DR e métricas de lag nativas. A contrapartida é assincronia, custo por instância e a responsabilidade do roteamento, que permanece inteiramente na camada de aplicação.