Multi-AZ no Amazon RDS: standby isolado ou cluster com duas réplicas de leitura

A documentação do RDS detalha como o Multi-AZ DB cluster, com writer e duas réplicas legíveis em três zonas, se diferencia do Multi-AZ DB instance tradicional, e por que a escolha trava decisões de capacidade, custo e tempo de failover.

Nota da redação: a tabela comparativa abaixo lista 'toda tabela precisa de chave primária' como requisito de schema do MySQL no Multi-AZ DB cluster. A documentação da AWS trata isso como recomendação forte ('we strongly recommend'), não como exigência obrigatória. Mantivemos o restante do conteúdo, mas o leitor deve considerar essa linha como recomendação de boas práticas, não regra que impede o funcionamento do recurso.

A documentação do RDS detalha como o Multi-AZ DB cluster, com writer e duas réplicas legíveis em três zonas, se diferencia do Multi-AZ DB instance tradicional, e por que a escolha trava decisões de capacidade, custo e tempo de failover.

A documentação do RDS detalha como o Multi-AZ DB cluster, com writer e duas réplicas legíveis em três zonas, se diferencia do Multi-AZ DB instance tradicional, e por que a escolha trava decisões de capacidade, custo e tempo de failover.

A AWS mantém, na documentação do Amazon RDS, duas arquiteturas bem distintas sob o mesmo rótulo "Multi-AZ". Quem desenha um ambiente de produção em sa-east-1 (ou qualquer outra região) precisa escolher entre o Multi-AZ DB instance clássico e o Multi-AZ DB cluster, que oferece duas réplicas de leitura de verdade. A documentação é clara num ponto que gera confusão recorrente: Multi-AZ DB cluster não é Aurora. São mecanismos de replicação diferentes, dentro do próprio RDS, aplicados a MySQL e PostgreSQL.

O modelo que já existia: Multi-AZ DB instance

No Multi-AZ DB instance tradicional, o RDS mantém um primary e um standby em zonas de disponibilidade separadas. O standby funciona como alvo de failover e não participa do roteamento de leitura, ao contrário dos readers do Multi-AZ DB cluster. Esse modelo continua sendo a opção mais simples e mais barata para quem só precisa de um plano B contra queda de AZ, sem pretensão de usar a réplica para escalar leitura.

O que o Multi-AZ DB cluster muda

O Multi-AZ DB cluster troca o standby oculto por dois reader DB instances, cada um em uma Availability Zone diferente da do writer, totalizando três AZs. A replicação passa a ser nativa do motor (não mais no nível de storage) e semissíncrona: o commit no writer só precisa de confirmação de pelo menos um dos dois readers, não dos dois. Isso dá menor latência de escrita que o Multi-AZ DB instance, segundo a própria documentação, e os readers passam a servir tráfego de leitura real, não só esperar um failover.

A diferença prática aparece em quem recebe a carga: aplicações que hoje mandam toda leitura para o primary porque a réplica Multi-AZ é inacessível podem redistribuir esse tráfego entre os dois readers do cluster, sem precisar manter réplicas de leitura separadas (e seu custo e complexidade de replicação assíncrona à parte).

A conta de instância muda junto

Essa capacidade extra vem com uma restrição que pesa no dimensionamento: Multi-AZ DB cluster só roda em classes de instância com armazenamento local NVMe, a família "d". A lista atual cobre db.c6gd, db.m5d, db.m6gd, db.m6id, db.m6idn, db.m8gd, db.r5d, db.r6gd, db.r6id, db.r6idn, db.r8gd e db.x2iedn, com uma observação específica: só db.c6gd tem o tamanho medium. Quem já opera com classes de uso geral sem sufixo d precisa recalcular a instância ao migrar, porque não existe caminho de Multi-AZ DB cluster em hardware sem storage local.

Failover depende do engine, não só da arquitetura

A documentação separa o comportamento de failover por motor, e a diferença importa para quem desenha SLA de recuperação:

Na prática, um cluster MySQL com um reader muito atrasado trava o failover até os dois estarem sincronizados; no PostgreSQL, o RDS promove o reader mais adiantado assim que ele aplica as transações pendentes, sem esperar o outro. Bancos legados sem chave primária em todas as tabelas MySQL são um risco concreto aqui: a ausência de PK já é causa documentada de erro de replicação nesse modelo.

Flow control: a válvula contra o lag crescente

Replica lag em Multi-AZ DB cluster é esperado, não é falha: o parâmetro que controla o limite varia por engine. Em MySQL, o parâmetro dinâmico rpl_semi_sync_master_target_apply_lag já vem ligado por padrão em 120 segundos; para desligar o flow control, o valor sobe ao máximo de 86.400 segundos (um dia inteiro). O delay atual injetado aparece rodando SHOW GLOBAL STATUS like '%flow_control%', e quem tem o Performance Insights ligado consegue ver o wait event /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond associado à query atrasada.

Em PostgreSQL o mecanismo é uma extensão com um background worker por instância, limite padrão de dois minutos de lag, ajustável via flow_control.target_standby_apply_lag. A função get_flow_control_stats mostra o delay em curso, e o wait event Extension aparece no pg_stat_activity. A documentação é honesta sobre o limite do recurso: flow control ajuda OLTP com transações curtas e concorrentes, mas não resolve lag causado por batch jobs ou operações longas, porque aí o problema não é throttle de escrita, é o tamanho da transação em si.

RDS Proxy e upgrade com menos downtime

Multi-AZ DB cluster integra com o Amazon RDS Proxy desde a criação do cluster, com connection multiplexing reduzindo o número de conexões físicas abertas no banco. O ganho mais concreto citado na documentação é o upgrade de versão secundária (minor version): com RDS Proxy na frente, a janela de indisponibilidade cai para um segundo ou menos. Para quem hoje agenda manutenção de madrugada para esses upgrades, isso muda o cálculo de quando aplicar patch.

Backup é do cluster, não da instância

O backup automatizado e o snapshot manual do Multi-AZ DB cluster capturam o volume de storage inteiro do cluster, não instância por instância. Isso simplifica a recuperação, mas também significa que não dá para restaurar seletivamente um único reader. Em compensação, a documentação garante um caminho de saída: um snapshot de Multi-AZ DB cluster pode ser restaurado tanto para um novo Multi-AZ DB cluster quanto para um deployment Single-AZ ou Multi-AZ DB instance comum, o que facilita testar o modelo de cluster sem ficar preso a ele se a conta de instância não fechar.

Quando vale a troca

Em resumo: a escolha é sobre padrão de leitura, não sobre moda de arquitetura. Faz sentido migrar para Multi-AZ DB cluster quando o workload tem leitura pesada que hoje sobrecarrega o primary, quando o tempo de failover precisa cair (a replicação nativa do engine tende a ser mais rápida que a promoção de storage) ou quando o time já pretende adotar RDS Proxy.

Vale manter o Multi-AZ DB instance clássico quando a carga de leitura é baixa, quando o catálogo de instâncias já usa classes fora da família d sem plano de troca, ou quando o motor usado não é nem MySQL nem PostgreSQL, os dois únicos mencionados na documentação do Multi-AZ DB cluster. Reserved DB instances também estão disponíveis para o modelo de cluster, então o desconto por compromisso de uso não é exclusividade do deployment antigo.

Fonte

1. Documentação do Amazon RDS, Multi-AZ DB clusters: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html

Fonte: Documentação do Amazon RDS — Multi-AZ DB clusters