Multi-AZ e backups automatizados

Multi-AZ é um recurso de alta disponibilidade do RDS que provisiona automaticamente uma réplica em espera síncrona em uma zona de disponibilidade diferente dentro da mesma região. A AWS gerencia a replicação de forma transparente: você se conecta usando um único endpoint DNS, e o RDS direciona o tráfego para a instância primária.

Se a instância primária falhar devido a problemas de hardware, rede ou sistema operacional, o RDS executará um failover automático para a instância em espera em aproximadamente 60–120 segundos. Sua aplicação se reconecta usando o mesmo endpoint DNS, que agora resolve para o endereço IP da instância em espera.

Você pode habilitar o Multi-AZ ao criar uma instância do RDS ou modificando uma instância existente. Ao habilitá-lo em uma instância em execução, a AWS cria um snapshot da instância primária, restaura-o em uma segunda AZ e, em seguida, sincroniza os dados usando a replicação nativa do mecanismo. Esse processo pode causar uma breve suspensão de E/S na instância primária; portanto, agende-o durante um período de baixo tráfego ou aceite o horário da janela de manutenção.

O Multi-AZ é compatível com todos os mecanismos do RDS, incluindo MySQL, PostgreSQL, MariaDB, Oracle e SQL Server, e não exige alterações no nível da aplicação.

Quando ocorre um failover, o RDS atualiza o CNAME DNS do endpoint do banco de dados para apontar para a instância em espera em cerca de 60 segundos. Sua aplicação precisa se reconectar depois de detectar uma interrupção da conexão TCP. Para minimizar os atrasos de reconexão:

• Use um TTL DNS curto (normalmente já definido pelo RDS como 5 segundos)
• Implemente espera progressiva exponencial com novas tentativas na lógica de conexão
• Use ferramentas de pool de conexões, como o RDS Proxy, que se reconectam automaticamente

O failover também pode ser acionado manualmente para manutenção ou alterações da classe da instância, permitindo atualizações com indisponibilidade quase nula quando o Multi-AZ está habilitado.

Uma confusão comum em provas é entre Multi-AZ (para disponibilidade) e réplicas de leitura (para escalabilidade). Principais diferenças:

• Instância em espera Multi-AZ: replicação síncrona, não atende tráfego de leitura, failover automático, mesma região
• Réplica de leitura: replicação assíncrona, atende tráfego de leitura, sem failover automático, pode abranger várias regiões

O Multi-AZ não melhora o desempenho de leitura — a instância em espera não pode ser acessada para consultas. Para melhorar a disponibilidade e também dimensionar as leituras, use Multi-AZ na instância primária e adicione réplicas de leitura separadamente.

O RDS cria automaticamente snapshots completos diários do banco de dados e captura logs de transações a cada 5 minutos. Juntos, esses recursos permitem a recuperação point-in-time (PITR) para qualquer segundo dentro do período de retenção dos backups. Você pode restaurar o banco de dados para o estado em que estava em qualquer momento dessa janela.

Os backups automatizados são habilitados por padrão e podem ser retidos por 1 a 35 dias. Definir a retenção como 0 desabilita os backups automatizados (e o PITR). A janela de backup é um período de 30 minutos que você especifica ou deixa a AWS escolher durante os horários de menor movimento.

A janela de backup é o período em que os instantâneos diários são feitos. Durante essa janela, a E/S de armazenamento pode ser brevemente interrompida em implantações Single-AZ. As implantações Multi-AZ fazem o instantâneo a partir da instância em espera, eliminando o impacto de E/S na instância primária.

A janela de manutenção é um período semanal separado em que a AWS aplica patches do sistema operacional, atualizações secundárias do mecanismo e modificações na instância. A prática recomendada é definir ambas as janelas para períodos de baixo tráfego e garantir que elas não se sobreponham.

Para restaurar um estado específico no tempo, o RDS primeiro restaura o instantâneo diário mais recente e depois reaplica os registros de transações até o carimbo de data e hora solicitado. O resultado é uma nova instância de banco de dados — o PITR nunca substitui a instância de origem, proporcionando um caminho seguro de recuperação que não interrompe a produção.

Depois que a instância restaurada estiver disponível, atualize a cadeia de conexão da sua aplicação para apontar para o novo ponto de extremidade, verifique a integridade dos dados e exclua a instância original se a recuperação tiver sido intencional. O tempo típico de restauração é proporcional ao tamanho do banco de dados e ao volume de registros desde o último instantâneo.

Além dos backups automatizados, você pode fazer instantâneos manuais a qualquer momento. Diferentemente dos backups automatizados, os instantâneos manuais não estão sujeitos ao período de retenção — eles permanecem até que você os exclua explicitamente.

Os instantâneos manuais são ideais para registrar o estado antes de uma migração importante do esquema, de uma atualização da aplicação ou no fim de um ciclo de faturamento para arquivamento por motivos de conformidade. Você também pode compartilhar instantâneos manuais com outras contas da AWS ou copiá-los entre Regiões para recuperação de desastre.

Você pode copiar instantâneos automatizados ou manuais para outra Região da AWS para recuperação de desastre. A cópia é um instantâneo completo armazenado na infraestrutura do S3 da Região de destino. Depois de copiado, você pode restaurar uma nova instância do RDS nessa Região se a sua Região primária ficar indisponível.

As cópias de instantâneos podem ser criptografadas no destino mesmo que a origem não seja criptografada — e vice-versa. As cópias entre Regiões geram custos de transferência de dados. Use o AWS Backup ou uma função do Lambda acionada pelo EventBridge para automatizar cópias periódicas de instantâneos entre Regiões.

O Amazon RDS Proxy fica entre a sua aplicação e o RDS e agrupa conexões de banco de dados. Isso é especialmente útil para funções do Lambda que podem abrir milhares de conexões de curta duração e esgotar o limite de conexões do banco de dados. O RDS Proxy multiplexa as conexões, fazendo com que o banco de dados veja muito menos conexões ativas.

Durante uma comutação automática do Multi-AZ, o RDS Proxy mantém as conexões da aplicação e restabelece a conexão com o banco de dados na nova instância primária, reduzindo o tempo de reconexão da aplicação para segundos em vez de minutos. O RDS Proxy também se integra ao Secrets Manager para alternar credenciais sem tempo de inatividade da aplicação.

O RDS agora oferece duas opções Multi-AZ: instância de banco de dados Multi-AZ (clássica, com uma instância em espera) e cluster de banco de dados Multi-AZ (duas instâncias em espera legíveis em AZs diferentes). O modo de cluster usa replicação semissíncrona e permite tráfego de leitura nas instâncias em espera, oferecendo maior disponibilidade e escalabilidade de leitura sem réplicas de leitura separadas.

Para o exame SAA-C03, a instância de banco de dados Multi-AZ clássica é a mais cobrada. Lembre-se: o cluster Multi-AZ é a opção mais recente, na qual as instâncias em espera podem atender leituras, enquanto a instância em espera clássica não pode.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: o Multi-AZ fornece replicação síncrona para uma instância em espera com comutação automática em 60–120 segundos; os backups automatizados permitem PITR para qualquer segundo dentro da janela de retenção (1–35 dias); e os instantâneos manuais permanecem indefinidamente e podem ser copiados entre Regiões para DR. A seguir, exploraremos as réplicas de leitura para distribuir o tráfego de leitura e melhorar a taxa de transferência de leitura.