A recuperação de desastres (DR) é uma estratégia de resiliência que usa procedimentos manuais para recuperar sua implantação quando o failover automático não pode ajudar. Ao contrário da alta disponibilidade, que fornece autocorreção automática para falhas de infraestrutura, a recuperação de desastres requer intervenção humana para restaurar a partir de backups.
Observação
O Modelo de responsabilidade compartilhada do MongoDB Atlas define os direitos complementares do MongoDB e de seus clientes em manter um ambiente de dados seguro e resiliente. Nesse framework, o MongoDB gerencia a segurança e a integridade operacional da plataforma subjacente, enquanto os clientes são responsáveis pelas políticas de configuração, gerenciamento e dados de suas implantações específicas. Para obter uma análise detalhada da propriedade em segurança e segurança operacional, consulte Modelo de responsabilidade compartilhada.
Quando usar a recuperação de desastre
Importante
Prefira alta disponibilidade quando possível. Use a recuperação de desastre como sua estratégia de resiliência primário somente quando a alta disponibilidade não for possível.
A recuperação de desastres é apropriada como sua principal estratégia de resiliência nas seguintes situações:
- Restrições geográficas
- Você não pode implantar em várias regiões com zonas de disponibilidade suficientes. Por exemplo, se você precisar implantar no Canadá, somente 2 regiões estarão disponíveis, evitando requisitos automáticos de quorum para failover.
- Otimização de custos
- Seu orçamento exige a minimização dos custos de infraestrutura. As implantações de alta disponibilidade de várias regiões ou multinuvem custam mais do que as implantações de uma única região com backups.
- Tolerância para recuperação manual
- Seu aplicativo tolera o tempo necessário para a intervenção manual e a restauração do backup (RTO em minutos a horas, em vez de segundos).
Observação
Mesmo se você usar alta disponibilidade, poderá se beneficiar dos procedimentos de recuperação de desastres para cenários que o failover automático não pode resolver, como corrupção de dados ou exclusão acidental. Para saber mais sobre como combinar as duas abordagens, consulte a Orientação para o planejamento de continuidade de negócios do Atlas.
Como os backups oferecem suporte à recuperação de desastre
Os backups são a principal ferramenta para implementar a recuperação de desastres. O Atlas oferece backups totalmente gerenciados e personalizáveis que permitem a recuperação manual quando o failover automático não ajuda.
Backup em nuvem
Quando você ativa o Backup em Nuvem para seu cluster, o Atlas usa os recursos de snapshot nativos do seu fornecedor de nuvem para criar backups incrementais que são imutáveis por padrão com tempos de restauração rápidos.
Como ele suporta DR:
Configure a frequência do snapshot (por hora, diário, semanal, mensal, anual) para atender aos requisitos de RPO.
Defina períodos de retenção de snapshots para atender às necessidades de compliance e recuperação.
Restaure snapshots para se recuperar da corrupção ou exclusão de dados.
Quando usar: cenários de recuperação de desastres padrão em que você pode tolerar uma perda de dados igual à frequência de seus snapshots. Por exemplo, snapshots de hora em hora resultam em até 1 hora de perda de dados.
Recuperação ponto com backup contínuo na nuvem
Quando você ativa o Backup em nuvem contínuo além do Backup em nuvem, o Atlas armazena dados de oplog junto com seus snapshots de Backup em nuvem, permitindo que o Atlas restaure seu cluster para um momento específico dentro de uma janela de restauração point-in-time (PIT) configurável.
Como ele suporta DR:
Restaure a qualquer momento dentro de uma janela de restauração do PIT configurável. O Atlas retém dados de oplog até a duração da janela de restauração e reproduz entradas de oplog na parte superior do snapshot do backup em nuvem mais próximo para restaurar no momento preciso especificado.
Obtenha um RPO de até 1 minuto.
Direcione precisamente o momento antes da ocorrência de corrupção ou exclusão de dados.
Quando usar: quando você precisa de perda mínima de dados ( RPO baixo ) ou recuperação precisa para um carimbo de data/hora específico.
Distribuição de snapshots multirregionais
Ao habilitar o Backup em Nuvem com uma política de cópia de snapshot, você pode configurar o Atlas para distribuir automaticamente cópias de seus snapshots e oplogs para regiões adicionais de provedor de nuvem em outras regiões.
Como ele suporta DR:
Atender aos requisitos de conformidade para backups distribuídos geograficamente.
Garante que os backups permaneçam acessíveis mesmo se a região primária falhar completamente.
Para um cluster multirregional, habilitar a opção Automatically Sync Copy Regions with Cluster Regions em sua política de cópias de snapshots permite que o Atlas distribua automaticamente snapshots para todas as regiões onde seu cluster está distribuído e mantém sua política de cópias de snapshots sincronizada à medida que você adiciona ou remove regiões. Isso permite que o Atlas use restaurações mais rápidas de conexão direta para restaurar regiões de cluster usando cópias de snapshot locais após uma interrupção regional , em vez de restaurações mais lentas por streaming entre regiões.
Quando usar: quando você precisar de proteção contra perda regional completa ou interrupções do fornecedor que excedam a configuração de HA.
Estratégia de backup Compensações RTO/RPO
As estratégias de backup protegem contra falhas de integridade de dados que o failover automático não consegue resolver, como corrupção de dados, exclusão acidental e perda total de implantação. Todas as estratégias de backup envolvem alguma perda de dados (RPO > 0) e tempos de recuperação mais longos (RTO em minutos a horas). As desvantagens estão na quantidade de dados que você pode perder e na complexidade operacional de cada abordagem.
Estratégia de backup | Casos de uso primário | RTO típico | RPO | Considerações operacionais | Considerações de custo |
|---|---|---|---|---|---|
Snapshots periódicos | Corrupção de dados, exclusão acidental, perda total da implantação. | Minutos a horas. | > 0 (até o intervalo de snapshot). | Definir cronograma/retenção. Teste regularmente os procedimentos de restauração. | O armazenamento cresce com frequência e retenção. A restauração incorre em custos de computação/saída. |
Backup contínuo com restauração point-in-time | Corrupção ou exclusão de dados em que o carimbo de data/hora "mau" é conhecido. | Minutos a horas. | > 0 (perto de zero, até segundos). | Configure janelas de restauração point-in-time (PIT). Monitore se há falhas. | Maior custo de armazenamento e backup do que os snapshots apenas. |
Distribuição de snapshots multirregionais | Perda de região ou provedor que também afeta os backups locais. | Minutos a horas (pode ser mais lento entre regiões). | > 0 (vinculado ao agendamento de snapshot). | Planeje e teste restaurações entre regiões. Gerenciar política de retenção. | Armazenamento adicional em várias regiões. Saída entre regiões na restauração. |
Todas as Recomendações de Paradigmas de Implantação
As seguintes recomendações se aplicam a todos os paradigmas de implantação.
Esta seção aborda os seguintes procedimentos de recuperação de desastres:
Interrupção de nó único
Se um único nó no seu conjunto de réplicas falhar devido a uma interrupção regional, sua implantação ainda deverá estar disponível, desde que você tenha seguido as melhores práticas. Se estiver lendo de secundários, poderá experimentar um desempenho degradado ou possíveis interrupções caso um nó secundário falhe, devido ao aumento da carga no cluster que então estará subprovisionado.
Você pode testar uma interrupção de nó primary no Atlas usando a funcionalidade Testar Failover Primário da UI do Atlas ou o endpoint da API de Administração do Atlas de Failover de Teste.
Interrupção regional
No evento de uma interrupção regional , os clusters multirregional realizam automaticamente uma eleição e identificam um novo nó primário, se necessário. Essa alteração de topologia é automaticamente comunicada ao aplicativo, permitindo que ele execute qualquer ação corretiva necessária. Para manter o tempo de atividade do aplicativo no evento de uma interrupção regional, seu aplicativo também deve ser implantado com uma topologia multirregional. Esse requisito se estende para incluir qualquer serviço de terceiros com o qual seu aplicativo possa ser integrado. Para **aprender** mais, consulte Paradigma de implantação **multirregional**.
Se uma única interrupção de região ou interrupção de multirregional degradar o estado do seu cluster, siga estas etapas:
Determine quais regiões provavelmente não serão afetadas pela interrupção atual
Dependendo da causa da interrupção, pode haver outras regiões em um futuro próximo que também sofrerão interrupções não programadas. Por exemplo, se as interrupções foram causadas por um desastre natural na costa leste dos Estados Unidos, você deverá evitar regiões na costa leste dos Estados Unidos caso haja problemas adicionais.
Adicione nós às regiões identificadas
Adicione o número necessário de nós para um estado normal em regiões que provavelmente não serão afetadas pela causa da interrupção.
Para reconfigurar um conjunto de réplicas durante uma interrupção adicionando regiões ou nós, consulte Reconfiguração de um conjunto de réplicas durante uma interrupção regional.
Você pode testar uma interrupção de região no Atlas usando o recurso Simular Interrupção da UI do Atlas ou o ponto de extremidade da API de Administração do Atlas de Simulação de Interrupção.
Interrupção do provedor de nuvem
Com clusters multinuvem, é possível selecionar nós elegíveis entre provedores de nuvem para manter a alta disponibilidade. Caso o provedor no qual seu nó primário está implantado fique indisponível, o Atlas elege automaticamente novos nós primários para garantir a operação contínua. Por exemplo, é possível criar nós elegíveis na AWS, no Google Cloud e no Microsoft Azure para garantir que, se um provedor de nuvem sofrer uma interrupção, um nó elegível em um provedor separado possa assumir automaticamente como nó primário do cluster. Para saber mais, consulte Paradigma de implantação multinuvem.
A maioria dos clusters multirregional do Atlas se recuperará automaticamente de uma única interrupção na região . Para saber mais, consulte Orientação para o Paradigma de Implantação de Alta Disponibilidade e multirregional do Atlas. Caso as interrupções regionais tenham colocado a maioria dos nós offline, você deve determinar quantos nós a mais precisam ser adicionados para que a maioria dos nós seja saudável.
No caso altamente improvável de um provedor de nuvem inteiro ficar indisponível, siga estas instruções para restaurar sua implantação online:
Identifique o provedor de nuvem alternativo no qual você gostaria de implantar seu novo cluster
Para obter uma lista de fornecedores de nuvem e informações, consulte Fornecedores de nuvem.
Se armazenar backups em vários provedores de nuvem, a interrupção de um provedor de nuvem implica que os backups armazenados no provedor de nuvem primário estarão necessariamente indisponíveis. Encontre o snapshot mais recente disponível do cluster antes do início da interrupção.
Para saber como visualizar seus snapshots de backup, consulte Visualizar snapshots de backup M10+.
Restaure o snapshot mais recente da etapa anterior no novo cluster
Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.
Alterne todos os aplicativos que se conectam ao cluster antigo para o cluster recém-criado
Para encontrar a nova string de conexão, consulte Conectar via bibliotecas de clientes. Revise sua pilha de aplicativo, pois você provavelmente precisará redistribuí-la no novo provedor de nuvem.
Interrupção do Atlas
No caso altamente improvável de o Plano de Controle do Atlas e a IU do Atlas não estarem disponíveis, seu cluster ainda estará disponível e acessível. Para saber mais, veja Reliability da plataforma. Abra um ticket de suporte com prioridade alta para investigar o problema mais a fundo.
Problemas de Capacidade de Recursos
Problemas de capacidade de recursos computacionais (como espaço em disco, RAM ou CPU) podem resultar de planejamento inadequado ou tráfego inesperado no banco de dados. Esse comportamento pode não ser resultado de um desastre.
Se um recurso computacional atingir o limite alocado e causar um desastre, siga estas instruções:
Identifique qual recurso computacional está esgotando usando o Painel de Desempenho em Tempo Real ou as métricas do Atlas
Para visualizar sua utilização de recursos na UI do Atlas, consulte Monitorar o desempenho em tempo real.
Para visualizar métricas com a API de administração do Atlas, consulte Monitoramento e registros.
Alocar os recursos necessários
Observe que o Atlas executará essa alteração de forma contínua, portanto, ela não deve ter nenhum impacto grande em seus aplicativos.
Para saber como alocar mais recursos, consulte Editar um cluster.
Falha de recurso
Importante
Esta é uma solução temporária destinada a reduzir o tempo de inatividade geral do sistema. Quando o problema subjacente for resolvido, mescle os dados do cluster recém-criado ao cluster original e ponto todos os aplicativos de volta para o cluster original.
Se um recurso computacional falhar e tornar seu cluster indisponível, siga estas instruções:
Abra um ticket de suporte
Restaure o backup mais recente no cluster recém-criado
Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.
Exclusão de dados de produção
Os dados de produção podem ser excluídos acidentalmente devido a erro humano ou a um bug no aplicativo criado sobre o banco de dados. Se o próprio cluster foi excluído acidentalmente, o Atlas pode reter o volume temporariamente.
Se o conteúdo de uma coleção ou de um banco de dados foi excluído, siga estas instruções para restaurar seus dados:
Criar uma cópia do estado atual da collection ou banco de dados, se ela contiver quaisquer dados
Você pode usar o mongoexport para criar uma cópia.
Restaurar seus dados
Se a exclusão ocorreu nas últimas 72 horas, e você configurou o backup contínuo, use a restauração de ponto no tempo (PIT) para restaurar a partir do ponto no tempo imediatamente anterior à exclusão.
Se a exclusão não ocorreu nas últimas 72 horas, restaure o backup mais recente de antes da ocorrência da exclusão no cluster.
Para saber mais, consulte Restaurar Seu Cluster.
Se você criou uma cópia dos seus dados, importe os novos dados que você exportou
Você pode usar o mongoimport com o modo upsert para importar seus dados e garantir que quaisquer dados que tenham sido modificados ou adicionados estejam corretamente replicados na coleção ou no banco de dados.
Falha do driver
Se um driver falhar, siga estas instruções:
Identifique a versão apropriada do driver para resolver o problema
Se você estiver usando um driver desatualizado, verifique se fazer upgrade para uma versão mais recente resolve o problema. A maioria dos problemas de driver é corrigida em versões mais recentes.
Se você atualizou recentemente seu driver e suspeita que a nova versão introduziu o problema, considere reverter para a versão de trabalho anterior.
Avalie se outras alterações são necessárias para migrar para a versão do driver de destino
Isso pode incluir código do aplicativo ou alterações de query. Por exemplo, pode haver alterações interruptivas se você estiver alternando entre as versões principais, ou novos recursos disponíveis se você estiver fazendo upgrade.
Corrupção de dados
Importante
Esta é uma solução temporária destinada a reduzir o tempo de inatividade geral do sistema. Quando o problema subjacente for resolvido, mescle os dados do cluster recém-criado ao cluster original e ponto todos os aplicativos de volta para o cluster original.
Se os seus dados subjacentes forem corrompidos, siga estas instruções:
Abra um ticket de suporte
Restaure o backup mais recente no cluster recém-criado
Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.