Como Configurar uma Implantação Multi-AZ do AWS RDS para Alta Disponibilidade

Configure o AWS RDS Multi-AZ para failover automático, manutenção mais segura e melhor disponibilidade do banco de dados em produção.

Como Configurar uma Implantação Multi-AZ do AWS RDS para Alta Disponibilidade

A disponibilidade do banco de dados é importante quando sua aplicação depende de um único endpoint do RDS. O AWS RDS Multi-AZ reduz o risco de falha de uma instância ou Zona de Disponibilidade, mantendo uma instância em espera em outra AZ e fazendo failover automaticamente quando a primária não consegue atender ao tráfego.

Este guia mostra como configurar uma implantação Multi-AZ do AWS RDS para uma instância de banco de dados nova ou existente, o que monitorar após a alteração e quais compensações esperar.

O que é o AWS RDS Multi-AZ?

Uma implantação Multi-AZ (Múltiplas Zonas de Disponibilidade) do AWS RDS cria uma réplica exata da sua instância de banco de dados em uma Zona de Disponibilidade (AZ) diferente, fisicamente isolada, dentro da mesma Região da AWS. Essa instância em espera opera em uma configuração de "espera ativa", o que significa que é continuamente atualizada com as alterações da instância primária usando replicação síncrona.

Como Funciona:

  1. Instância Primária: Sua aplicação se conecta e escreve dados na instância de banco de dados primária.
  2. Replicação Síncrona: Todas as gravações de dados na instância primária são replicadas de forma síncrona para a instância em espera. Isso garante que a instância em espera esteja sempre atualizada com a primária, minimizando a perda de dados durante um failover.
  3. Failover Automático: Em caso de falha de infraestrutura que afete a instância primária (por exemplo, uma interrupção de AZ, falha de hardware da instância, problema de rede ou falha do mecanismo de banco de dados), o AWS RDS alterna automaticamente para a réplica em espera. A duração do failover varia de acordo com o mecanismo, a carga de trabalho e o comportamento do cache DNS, portanto, sua aplicação deve usar lógica de reconexão. O endpoint do banco de dados permanece o mesmo, então suas aplicações não precisam de uma nova string de conexão.
  4. Endpoint Único: Tanto a instância primária quanto a em espera compartilham um único endpoint DNS. Suas aplicações se conectam a este endpoint, e a AWS gerencia o redirecionamento para a instância primária ativa no momento.

Benefícios das Implantações Multi-AZ

Configurar o RDS com Multi-AZ fornece várias vantagens cruciais para cargas de trabalho de produção:

  • Alta Disponibilidade: O failover automatizado para uma réplica em espera em uma AZ diferente garante que seu banco de dados permaneça operacional mesmo se a AZ primária sofrer uma interrupção. Isso reduz significativamente o tempo de inatividade.
  • Durabilidade dos Dados: A replicação síncrona garante que todas as transações confirmadas estejam presentes tanto na instância primária quanto na em espera. Isso minimiza o risco de perda de dados durante um failover.
  • Recuperação de Desastres: Ao abranger várias Zonas de Disponibilidade, seu banco de dados é protegido contra falhas no nível da AZ, formando um componente crítico de sua estratégia de recuperação de desastres.
  • Operações Simplificadas: A AWS lida com o monitoramento, replicação e processo de failover automaticamente. Você não precisa configurar replicação baseada em host, gerenciar instâncias em espera ou orquestrar failovers manualmente.
  • Janelas de Manutenção: Durante a manutenção planejada (por exemplo, aplicação de patches no SO ou atualizações do mecanismo de banco de dados), a AWS faz failover automaticamente para a instância em espera, realiza a manutenção na antiga primária e depois volta. Isso minimiza o tempo de inatividade da aplicação.
  • Desempenho (Latência de Gravação): Embora a replicação síncrona introduza inerentemente um ligeiro aumento na latência de gravação em comparação com uma implantação de AZ única (devido à confirmação de gravações em dois locais), isso geralmente é insignificante para a maioria das aplicações e é uma compensação válida pela maior disponibilidade.

Pré-requisitos

Antes de começar, certifique-se de ter:

  • Uma Conta AWS com permissões apropriadas para criar e gerenciar instâncias RDS.
  • Uma compreensão básica de Regiões AWS, Zonas de Disponibilidade e Nuvens Privadas Virtuais (VPCs).

Guia de Configuração Passo a Passo

Opção 1: Criando uma Nova Instância RDS com Multi-AZ

Esta é a abordagem recomendada para novas implantações, garantindo alta disponibilidade desde o primeiro dia.

  1. Navegue até o Console do RDS: Faça login no Console de Gerenciamento da AWS e abra o console do Amazon RDS.
  2. Criar Banco de Dados: No painel de navegação, escolha Bancos de Dados e clique em Criar banco de dados.
  3. Escolher Método de Criação de Banco de Dados: Selecione Criação padrão.
  4. Escolher Opções de Mecanismo:
    • Tipo de mecanismo: Selecione o mecanismo de banco de dados desejado (por exemplo, MySQL, PostgreSQL, SQL Server, Oracle).
    • Versão do mecanismo: Escolha a versão específica.
  5. Modelos: Escolha o modelo apropriado. Para produção, use um modelo orientado a produção e ainda verifique a configuração Multi-AZ antes de criar o banco de dados.
  6. Configurações:
    • Identificador da instância de banco de dados: Forneça um nome exclusivo para sua instância de banco de dados.
    • Nome de usuário mestre e Senha mestra: Defina as credenciais para o usuário principal do banco de dados.
  7. Tamanho da Instância de Banco de Dados: Selecione a classe de instância que atende aos seus requisitos de desempenho.
  8. Armazenamento: Configure o tipo de armazenamento e o armazenamento alocado.
  9. Disponibilidade e Durabilidade: Esta é a etapa crucial para o Multi-AZ:
    • Em Implantação Multi-AZ, selecione Sim (Criar uma instância em espera).
    • (Opcional) Se você selecionou o modelo "Produção" anteriormente, esta opção será pré-selecionada.
  10. Conectividade:
    • VPC: Selecione a VPC onde seu banco de dados residirá.
    • Grupo de sub-redes: Certifique-se de ter um grupo de sub-redes de banco de dados que abranja várias Zonas de Disponibilidade. O RDS usará isso para colocar as instâncias primária e em espera em diferentes AZs.
    • Acesso público: Escolha Não para ambientes de produção para práticas recomendadas de segurança.
    • Grupos de segurança da VPC: Anexe um grupo de segurança apropriado que permita tráfego de entrada para a porta do seu banco de dados a partir de seus servidores de aplicação.
  11. Autenticação do Banco de Dados: Escolha seu método de autenticação preferido.
  12. Monitoramento, Insights de Desempenho, Exportação de Logs, Manutenção: Configure conforme seus requisitos operacionais.
  13. Criar banco de dados: Revise todas as suas configurações e clique em Criar banco de dados.

A AWS provisionará sua instância primária e, em seguida, criará e sincronizará a réplica em espera em uma Zona de Disponibilidade diferente. Este processo pode levar algum tempo, dependendo do tamanho da instância.

Opção 2: Modificando uma Instância RDS Existente para Multi-AZ

Você pode habilitar o Multi-AZ para uma instância RDS de AZ única existente sem tempo de inatividade.

  1. Navegue até o Console do RDS: Faça login no Console de Gerenciamento da AWS e abra o console do Amazon RDS.
  2. Selecionar Banco de Dados: No painel de navegação, escolha Bancos de Dados e selecione a instância RDS que deseja modificar.
  3. Modificar Instância: Clique no botão Modificar.
  4. Disponibilidade e Durabilidade: Role para baixo até a seção Disponibilidade e Durabilidade.
    • Em Implantação Multi-AZ, selecione Sim (Criar uma instância em espera).
  5. Continuar: Revise outras configurações (classe de instância, armazenamento, etc.) e faça quaisquer outras alterações necessárias, depois clique em Continuar.
  6. Agendamento de Modificações:
    • Aplicar imediatamente: Escolher esta opção inicia a alteração imediatamente. O RDS cria a instância em espera em segundo plano enquanto a primária permanece disponível, embora você possa observar maior latência de E/S durante a sincronização. A AWS normalmente não exige uma interrupção planejada apenas para habilitar o Multi-AZ, mas failovers posteriores ou eventos de manutenção ainda podem interromper as conexões.
    • Aplicar durante a próxima janela de manutenção programada: Esta opção aplicará as alterações durante sua janela de manutenção definida, minimizando a interrupção durante os horários de pico.
  7. Modificar instância de banco de dados: Clique em Modificar instância de banco de dados.

A AWS iniciará o processo de criação da réplica em espera e sincronização com sua instância primária. Durante este tempo, seu banco de dados permanecerá online, mas você pode observar um breve evento de failover quando a configuração Multi-AZ for finalizada.

Monitorando Sua Implantação Multi-AZ

Após configurar o Multi-AZ, é essencial monitorar seu status:

  1. Console do RDS: Vá para o console do RDS e selecione sua instância de banco de dados.
  2. Guia Detalhes: Na seção Conectividade e segurança, você verá Multi-AZ listado como Sim. Em Disponibilidade e durabilidade, deve mostrar sua instância como estando em uma implantação Multi-AZ.
  3. Eventos: Verifique a guia Logs e eventos para eventos relacionados a failovers, criação de instâncias ou atividades de manutenção. A AWS registrará eventos para failovers (por exemplo, RDS-EVENT-0026 - A instância de banco de dados XXX passou por failover).

Testando Failover (Opcional, mas Recomendado)

Embora a AWS gerencie failovers automaticamente, é uma boa prática entender e ocasionalmente testar o mecanismo de failover em um ambiente que não seja de produção.

Acionando um Failover:

  1. Reinicializar com Failover: Selecione sua instância Multi-AZ no console do RDS. No menu Ações, escolha Reinicializar. Certifique-se de selecionar a opção "Reinicializar com failover?".
    • Esta ação força o RDS a alternar a instância primária para a réplica em espera, simulando uma interrupção não planejada. Sua aplicação deve esperar uma breve desconexão enquanto o endpoint começa a resolver para a nova primária.
  2. Observar Eventos: Após iniciar um failover, monitore a guia Logs e eventos para sua instância. Você deve ver eventos indicando que um failover ocorreu e que a nova primária está ativa.

Considerações e Melhores Práticas

  • Custo: As implantações Multi-AZ incorrem em custos mais altos do que as implantações de AZ única, porque você está efetivamente executando duas instâncias de banco de dados (primária e em espera), mesmo que apenas uma esteja servindo tráfego ativamente a qualquer momento.
  • Réplicas de Leitura vs. Multi-AZ: Entenda a diferença. Multi-AZ é para alta disponibilidade e durabilidade (gravações). Réplicas de Leitura são para escalabilidade de leitura e melhoria do desempenho de leitura. Elas podem ser usadas juntas; você pode criar uma primária Multi-AZ e depois ter réplicas de leitura para escalar aplicações com uso intensivo de leitura.
  • Impacto no Desempenho: Embora o Multi-AZ melhore a disponibilidade, a replicação síncrona pode introduzir um ligeiro aumento na latência de gravação em comparação com AZ única. Para a maioria das aplicações, essa sobrecarga é mínima.
  • Grupos de Sub-redes: Certifique-se de que seu Grupo de Sub-redes de Banco de Dados inclua sub-redes em pelo menos duas Zonas de Disponibilidade diferentes. Isso permite que o RDS coloque suas instâncias primária e em espera em AZs separadas.
  • Grupos de Segurança: Configure adequadamente seus grupos de segurança da VPC para permitir tráfego de seus servidores de aplicação para o endpoint do RDS.
  • Suporte a Mecanismos de Banco de Dados: O Multi-AZ é suportado pela maioria dos mecanismos de banco de dados populares, incluindo MySQL, PostgreSQL, SQL Server, Oracle e MariaDB.

Conclusão

Use o AWS RDS Multi-AZ para bancos de dados de produção onde o failover automático é mais importante do que o custo extra e a possível sobrecarga de latência de gravação. Depois de habilitá-lo, confirme que seu grupo de sub-redes de banco de dados abrange pelo menos duas AZs, teste o comportamento de reconexão da aplicação em um ambiente que não seja de produção e monitore os eventos do RDS para que os failovers não surpreendam sua equipe.