Observação
Esta funcionalidade está disponível para clusters M10 ou superiores. Para saber mais sobre quais recursos estão disponíveis para clusters gratuitos, consulte Limites de cluster gratuito do Atlas , e para clusters Flex, consulte Limitações do Atlas Flex.
Seus aplicativos devem lidar com uma mudança de primário sem nenhum tempo de inatividade.
Em clusters Atlas Core:
- O Atlas realiza eleições de conjuntos de réplicas quando faz alterações na configuração, como atualizações de patches e eventos de escalabilidade, e quando ocorrem falhas.
Em clusters Atlas Infinite:
A camada de armazenamento coordena o failover em vez de uma eleição entre os nós de computação. Um nó de computação auxiliar se torna o nó primário sem repetição de oplog ou inicialização a frio.
O nó primary pode ser alterado durante a manutenção do sistema operacional ou da VM, aumento ou redução vertical, atualizações de versão do MongoDB e falhas.
O Atlas mantém a disponibilidade durante a reinicialização contínua.
Para saber como criar um aplicativo resiliente, consulte Criar um Aplicativo Resiliente com o MongoDBAtlas.
Você pode ativar as gravações repetíveis adicionando retryWrites=true à cadeia de conexão do URI do Atlas. Para saber mais, consulte Gravações repetíveis.
Você pode usar a interface de usuário e a API do Atlas para testar a falha do conjunto de réplicas primário em seu cluster Atlas e observar como seu aplicação lida com um failover de conjunto de réplicas.
Acesso necessário
Para iniciar um teste de failover, você deve ter acesso Organization Owner, Project Owner, Project Cluster Manager ou Project Stream Processing Owner ao projeto.
Pré-requisitos
Antes de testar a falha do conjunto de réplicas primário, você deve atender às seguintes condições:
Todas as alterações pendentes no seu cluster devem ser concluídas.
Todos os membros do cluster devem estar em um estado saudável com dados de monitoramento atualizados.
Cada conjunto de réplicas ou fragmento deve ter um nó primário.
Qualquer membro do cluster deve ter um atraso de replicação inferior a 10 segundos.
Todos os membros do seu cluster devem ter pelo menos 5% do espaço disponível em disco restante.
Todas os oplogs de nó primário devem ter espaço suficiente para uma operação de três horas.
Teste o Processo de Failover Primário
Importante
Certifique-se de que seu Atlas cluster esteja íntegro antes de testar o failover primary. Caso contrário, a Atlas poderá rejeitar sua solicitação.
Quando você envia uma solicitação para testar o failover primário, o Atlas simula um evento de failover. Durante este processo:
O Atlas desliga o primaryatual.
Os nós do conjunto de réplicas realizam uma eleição para escolher qual dos secundários se tornará o novo primário. Em média, uma eleição leva aproximadamente cinco segundos.
O Atlas traz o primário original de volta para o conjunto de réplicas como um secundário. Quando o primário antigo se juntar novamente ao conjunto de réplicas, ele será sincronizado com o novo primário para recuperar todas as gravações que ocorreram durante seu tempo de inatividade.
As instruções a seguir descrevem o comportamento do Atlas durante sobreposições e ao testar failover em clusters fragmentados:
Nos clusters do Atlas Core, o primary original pode ter aceito operações de gravação que não foram replicadas com êxito para os secundários antes de ser desativado. Quando esse primário se junta novamente ao conjunto de réplicas e começa a sincronizar, ele reverte as gravações não replicadas. Para saber mais,consulte Rollbacks durante o failover no Atlas.
Nos clusters do Atlas Infinite, não ocorrem rollbacks. A camada de armazenamento confirma as operações de gravação, portanto, um antigo nó primário não tem gravações não replicadas para reverter.
Somente os processos do
mongosque estão nas mesmas instâncias que os primários dos conjuntos de réplicas no cluster fragmentado são reiniciados.Os primaries dos conjuntos de réplicas no cluster fragmentado são reiniciados em paralelo.
Para iniciar um teste de failover para o agrupamento especificado em seu projeto utilizando o Atlas CLI, execute o seguinte comando:
atlas clusters failover <clusterName> [options]
Para saber mais sobre a sintaxe e os parâmetros do comando, consulte a documentação do Atlas CLI para failover de clusters do atlas.
Para realizar um teste do failover primário usando a IU do Atlas:
No Atlas, acesse a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Para o cluster em que você deseja realizar testes de failover, clique no botão ....
Clique em Test Resilience.
No modal Test Resilience, clique na aba Primary Failover. O Atlas exibe as etapas necessárias para simular um evento de failover. Para saber mais, consulte Teste o processo de failover.
Clique em Restart Primary para iniciar o teste. O Atlas exibe os resultados do seu processo de failover simulado no modal Test Resilience.
Verificar o Failover
Para verificar se o failover foi bem-sucedido:
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Solução de Problemas de Failover
Se o seu aplicativo não lidar com o failover normalmente, certifique-se do seguinte:
Você está usando o Formato de Conexão SRV.
Você está usando a versão mais recente do driver.
Você implementou a lógica de nova tentativa apropriada em seu aplicativo.