Menu Docs

Orientações para a recuperação de desastres do Atlas

É fundamental que as empresas planejem a recuperação de desastres. É altamente recomendável que você prepare um plano abrangente de recuperação de desastres (DR) que inclua elementos como:

  • Seu objetivo de ponto de recuperação designado (RPO)

  • Seu objetivo de tempo de recuperação (RTO) designado

  • Processos automatizados que facilitam o alinhamento com esses objetivos

Utilize as recomendações desta página para se preparar e responder a desastres.

Para aprender mais sobre configurações proativas de alta disponibilidade que podem ajudar na recuperação de desastres, consulte Configurações recomendadas para alta disponibilidade e recuperação.

Para aprender sobre os recursos do Atlas que oferecem suporte à recuperação de desastre, consulte as seguintes páginas no Centro de Arquitetura Atlas:

Use as seguintes recomendações de recuperação de desastres para criar um plano de recuperação de desastres para sua organização. Estas recomendações fornecem informações sobre as etapas a serem seguidas em caso de evento de desastre.

É fundamental que você teste os planos nesta seção regularmente (idealmente trimestralmente, mas pelo menos semestralmente). Os testes geralmente ajudam a preparar a equipe de gerenciamento de banco de dados empresarial (EDM) para responder a desastres e, ao mesmo tempo, ajudar a manter as instruções atualizadas.

Alguns testes de recuperação de desastres podem exigir ações que não podem ser executadas por usuários do EDM. Nesses casos, abra um caso de suporte com o objetivo de realizar interrupções sintéticas pelo menos uma semana antes de quando você planeja executar um exercício de teste.

Esta seção aborda os seguintes procedimentos de recuperação de desastres:

Se um único nó no seu conjunto de réplicas falhar devido a uma interrupção regional, sua implantação ainda deve estar disponível, desde que você tenha seguido as melhores práticas. Se você estiver lendo de nós secundários, poderá experimentar um desempenho degradado porque terá um nó a menos para leitura.

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.

Se uma única interrupção de região ou interrupção de multirregional degradar o estado do seu cluster, siga estas etapas:

1
2

Você pode encontrar informações sobre a saúde do cluster na aba Overview da IU do Atlas.

3

Com base em quantos nós estão online, determine quantos novos nós são necessários para restaurar o conjunto de réplicas a um estado normal.

Um estado normal é um estado no qual a maioria dos nós está disponível.

4

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.

5

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 Reconfigurar um conjunto de réplicas durante uma interrupção regional.

6

Além de adicionar nós para restaurar seu conjunto de réplicas para um estado normal, você pode adicionar nós adicionais para corresponder à topologia do seu conjunto de réplicas antes do desastre.

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.

No caso altamente improvável de que um provedor de nuvem inteiro fique indisponível, siga estas etapas para restaurar sua implantação online:

1

Você precisará dessas informações mais tarde neste procedimento para restaurar sua implantação.

2

Para obter uma lista de fornecedores de nuvem e informações, consulte Fornecedores de nuvem.

3

Para saber como visualizar seus snapshots de backup, consulte Visualizar snapshots de backup M10+.

4

Seu novo cluster deve ter uma topologia idêntica ao cluster original.

Como alternativa, em vez de criar um novo cluster completo, você também pode adicionar novos nós hospedados por um provedor de nuvem alternativo ao cluster existente.

5

Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.

6

Para encontrar a nova string de conexão, consulte Conectar via Drivers. Revise sua pilha de aplicativos, pois provavelmente precisará redistribuí-la no novo provedor de nuvem.

No evento altamente improvável de que o Plano de Controle do Atlas e a IU do Atlas estejam indisponíveis, seu cluster ainda estará disponível e acessível. Para saber mais, veja Confiabilidade da Plataforma. Abra um ticket de suporte de alta prioridade para investigar isso mais a fundo.

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:

1

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.

2
3

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.

4

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:

2
3

Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.

4

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 banco de dados foi excluído, siga estas etapas para restaurar seus dados:

1
2

Você pode usar o mongoexport para criar uma cópia.

3

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.

4

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 refletidos corretamente na coleção ou banco de dados.

Se um driver falhar, siga estas etapas:

1

Você pode colaborar com a equipe de suporte técnico durante esta etapa.

Se você determinar que a reversão para uma versão anterior do driver corrigirá o problema, continue para a próxima etapa.

2
3

Isso pode incluir alterações no código do aplicativo ou alterações na consulta. Por exemplo, pode haver uma alteração interruptiva se você estiver alternando entre versões principais e secundárias.

4
5

Certifique-se de que quaisquer outras alterações da etapa anterior estejam refletidas no ambiente de produção.

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 etapas:

2
3

Para saber como restaurar seu snapshot, consulte Restaurar seu cluster.

4
5