Sites de DR e estratégias comuns de DR do Amazon RDS - AWS Orientação prescritiva

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 aplicativos de TI essenciais aos negócios quando um local primário é afetado por um desastre. Os sites de DR geralmente são construídos em um local remoto para ajudar a garantir que o desastre que afeta o local principal não afete também o local secundário. Os sites de DR disponíveis para você AWS podem ser amplamente categorizados como DR próximos e DR distantes:

  • O Near DR geralmente é chamado de recuperação de desastres na 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 manutenção planejada.

  • O Far DR costuma ser chamado de recuperação de desastres entre regiões. A solução é configurada 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íncrono

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 (próxima à DR) é uma solução AWS gerenciada próxima à DR 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 principal ficar indisponível devido a uma interrupção no nível da zona de disponibilidade, promoverá AWS automaticamente o banco de dados em espera para a função principal. Isso garante o mínimo de perda de dados e tempo de inatividade. No entanto, é importante observar que a implantação do Multi-AZ não protege contra interrupções em nível regional. Ele também não fornece nenhum recurso de DR fora do 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, você pode usar as seguintes opções:

  • Snapshots automatizados gerenciados usando AWS Backup — 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 point-in-time recuperação (PITR). Com AWS Backup, você pode tirar instantâneos, 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 Região da AWS ou em uma região diferente.

    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 principal. Você pode usar 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 PITR do Amazon RDS — os snapshots do RDS são uma opção manual de DR. Você define uma configuração de point-in-time snapshot 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 ativar a replicação entre regiões para replicar as alterações do banco de dados principal para o banco de dados auxiliar em uma região diferente.

    A replicação de snapshots 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 principal 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 regional.