View a markdown version of this page

Sites de DR e estratégias comuns de DR do Amazon RDS - AWS Recomendações

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Sites de DR e estratégias comuns de DR do Amazon RDS

Um site de recuperação de desastres (DR) é um local secundário usado por uma organização para restaurar sua infraestrutura e aplicações de TI essenciais aos negócios quando um site primário é afetado por um desastre. Os sites de DR geralmente são criados em um local remoto para ajudar a garantir que o desastre que afeta o site primário não afete também o site secundário. Os sites de DR disponíveis para você na AWS podem ser amplamente categorizados como DR próxima e DR distante:

  • A DR próxima é muitas vezes referida como recuperação de desastres dentro da região. A solução de DR é configurada entre as zonas de disponibilidade para proteger o sistema quando há uma interrupção na zona de disponibilidade ou uma manutenção planejada.

  • A DR distante é muitas vezes referida como recuperação de desastres entre regiões. A solução é configurada entre Regiões da AWS para proteger o sistema contra interrupções em toda a região ou para realizar transições planejadas para atender às políticas de conformidade.

DR síncrona

Na DR síncrona, os dados são replicados para o site de DR ao mesmo tempo em que novos dados são criados ou atualizados no site primário. Para obter uma solução síncrona de DR para bancos de dados de edição padrão, você pode usar a implantação multi-AZ.

A implantação multi-AZ (DR próxima) é uma solução de DR próxima gerenciada pela AWS que fornece replicação síncrona do seu banco de dados do RDS para uma instância em espera em uma zona de disponibilidade diferente na mesma região. Se o banco de dados primário ficar indisponível devido a uma interrupção no nível da zona de disponibilidade, a AWS promoverá automaticamente o banco de dados em espera para a função primária. Isso garante perda de dados e tempo de inatividade mínimos. No entanto, é importante observar que a implantação multi-AZ não protege contra interrupções em nível de região. Ela também não fornece nenhum recurso de DR fora da Nuvem AWS.

Opções de DR assíncrona

Na DR assíncrona, a replicação não é executada ao mesmo tempo em que as alterações são feitas na primária. Os dados são replicados somente nos intervalos definidos pelo objetivo do ponto de recuperação. Para implementar uma solução de DR assíncrona, é possível usar as seguintes opções:

  • Snapshots automatizados gerenciados usando o AWS Backup: O AWS Backup é um serviço de backup totalmente gerenciado que automatiza o backup e a recuperação do seu banco de dados do Amazon RDS com base nas suas configurações de recuperação para um ponto no tempo (PITR). Com o AWS Backup, você pode obter snapshots e criar agendamentos de backup, políticas de retenção e planos de backup para proteger seus dados contra exclusão acidental, corrupção ou falhas de hardware. Você pode restaurar seu banco de dados em uma nova instância do RDS na mesma Região da AWS ou em outra região.

    O AWS Backup é uma opção de DR ativa-passiva porque você precisa iniciar manualmente o processo de restauração no caso de uma falha no banco de dados primário. Você pode usar o AWS Backup em conjunto com uma implantação multi-AZ, combinando soluções síncronas e assíncronas para fornecer uma camada adicional de proteção contra perda de dados.

  • Replicação de snapshots para PITR do Amazon RDS: os snapshots do RDS são uma opção manual de recuperação de desastres. Você define uma configuração de snapshot em um ponto no tempo para sua instância de banco de dados do RDS, e os snapshots são armazenados no Amazon Simple Storage Service (Amazon S3). Em seguida, você pode habilitar a replicação entre regiões para replicar as alterações do banco de dados primário para o banco de dados auxiliar em outra região.

    A replicação de snapshots para PITR do Amazon RDS é uma opção de DR ativa-passiva porque você precisa iniciar manualmente o processo de restauração e promover o banco de dados em espera à função primária se o banco de dados primário original falhar. No entanto, essa opção oferece mais flexibilidade do que a implantação multi-AZ, e você pode usá-la para se proteger contra interrupções em nível de região.