Página inicial do Docs → Iniciar e gerenciar o MongoDB → MongoDB Atlas
Testar failover primário
Nesta página
Observação
Esta funcionalidade não está disponível para clusters gratuitos M0 e clusters M2 e M5. Para saber mais sobre quais recursos estão indisponíveis, consulte os limites do Atlas M0 (Free Cluster), M2 e M5.
O Atlas realizaeleições de conjuntos de réplicas quando faz alterações na configuração, como atualizações de patches, eventos de escalabilidade e quando ocorrem falhas. Seus aplicativos devem lidar com as eleições de conjuntos de réplicas sem nenhum tempo de inatividade. Para saber como criar um aplicativo resiliente, consulte Criar um Aplicativo Resiliente com o MongoDBAtlas.
Você pode ativar as gravações que podem ser repetidas adicionando retryWrites=true à cadeia de conexão do URI do Atlas. Para saber mais, consulte Retryable Writes.
Você pode usar a UI e API do Atlas para testar a falha do primary do conjunto de réplicas no Atlas cluster e observar como o aplicativo administra um failover de conjunto de réplicas.
Acesso obrigatório
Para iniciar um teste de failover, você deve ter acesso Organization Owner ou Project 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 primary atual.
Os nós do conjunto de réplicas realizam uma eleição para escolher qual dos secundários se tornará o novo primary.
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:
Se o primary original aceitou operações de escrita que não foram replicadas com êxito para os secundários quando o primary foi desativado, o primary reverte essas operações de escrita quando se junta novamente ao conjunto de réplicas e começa a sincronizar. Para saber mais, consulte Rollbacks durante o failover do conjunto de réplicas. Entre em contato com o suporte do MongoDB para obter assistência na resolução de rollbacks.
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.
Verificar o Failover
Para verificar se o failover foi bem-sucedido:
Inicie sessão na UI do Atlas e clique em Database.
Clique no nome do cluster para o qual você realizou o teste de failover.
Observe as seguintes alterações na lista de nós na guia Overview:
O nó
PRIMARYoriginal agora é um nóSECONDARY.Um antigo nó
SECONDARYé agora o nóPRIMARY.
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.