Resumo

  • No Atlas Core com Search Nodes separados, a pausa apaga os dados desses nós. A retomada cria novos nós e reconstrói índices; $search e $vectorSearch ficam indisponíveis durante o trabalho.
  • As métricas de busca anteriores à pausa não são preservadas. Uma comparação confiável precisa de registros mantidos pelo comprador.
  • O cluster pausado paga apenas pelo armazenamento. A conta da economia também deve considerar a preparação da volta e os valores realmente cobrados pelos recursos ativos.

A planilha fecha antes de a loja abrir

O horário sem uso entra facilmente na planilha de economia de nuvem. O horário que alguém precisa reservar para deixar tudo pronto de novo costuma morar em uma agenda diferente. MongoDB Atlas oferece um bom teste para saber se a empresa juntou os dois documentos.

Ao pausar um cluster Atlas Core com nós de busca separados, o serviço apaga os dados dos Search Nodes. Na retomada, cria novos nós e reconstrói os índices. Durante a reconstrução, os estágios $search e $vectorSearch ficam indisponíveis. Esse é o recorte aqui: o Atlas Infinite, em prévia pública, ainda não oferece esses nós.

A busca pronta sai de cena e depois precisa ser preparada outra vez. MongoDB executa automaticamente a reconstrução, o que poupa trabalho de montagem. O cliente ainda precisa encaixar essa montagem no horário em que prometeu entregar seu serviço. Contratar uma equipe para reformar a loja não escolhe, por si só, a hora de reabrir.

Pense em uma demonstração de catálogo. É um cenário de decisão: a aplicação pode abrir, a conexão com a base pode funcionar, e os índices de busca podem continuar em preparação. A pessoa que testa o acesso ao banco e a pessoa que procura um produto na demonstração estão verificando entregas diferentes. A segunda precisa da busca para cumprir o compromisso comercial.

O desconto tem fundamento; a volta tem trabalho

As regras de custo do cluster são claras: durante a pausa, o Atlas cobra apenas armazenamento, inclusive a capacidade padrão. Para um ambiente que passa longos períodos sem uso, retirar os recursos de computação da rotina oferece uma oportunidade real de reduzir despesas.

O cálculo fica incompleto quando termina aí. Quem vai retomar o ambiente com antecedência? Quem vai conferir os índices? Quem testa a consulta que será usada? Distribuir essas tarefas por pessoas diferentes facilita o desaparecimento do custo total. O responsável pelo consumo apresenta o que deixou de gastar; o responsável pelo produto absorve a preparação como se fosse apenas mais uma tarefa da manhã.

Na cobrança de Search Nodes, contam o número de nós, a configuração e o tráfego com os nós de banco de dados. A cobrança é horária, e uma fração de hora é cobrada como hora inteira. A avaliação deve confrontar a fatura efetiva com a sequência de retomada. A tabela cobra recursos; ela não estabelece que o relógio só começa quando a busca já passou no teste de negócio.

Uma parada longa consegue diluir um único esforço de preparação. Paradas curtas repetidas fazem a empresa refazer esse percurso muitas vezes. Por isso, a pergunta comercial mais útil é a frequência com que se aceita trocar uma busca pronta pela obrigação de reconstruí-la. Um ambiente reservado para testes tem uma agenda; uma ferramenta convocada a qualquer momento tem outra.

A busca reaparece, a memória do gráfico fica para trás

A documentação de métricas acrescenta uma consequência importante para a própria avaliação da economia: as métricas de busca anteriores à pausa não são retidas. Depois da retomada, estão disponíveis somente as dos novos nós.

Se a equipe quer comparar o antes e o depois, precisa guardar sua referência antes de desligar. Consultas representativas, resultados esperados, tempos e condições de execução formam um registro enxuto e útil. Mudanças no volume de dados, nos índices ou na configuração devem aparecer junto das medidas, para não virarem supostas melhorias provocadas pela pausa.

Um gráfico novo pode mostrar o presente com precisão e ainda deixar a reunião sem passado. A conversa então vira um concurso entre a lembrança de quem demonstrava o produto e o número de quem acompanha o gasto. Medidas próprias colocam as duas áreas na mesma linha do tempo. Também permitem avaliar a próxima configuração sem começar toda a discussão do zero.

Trocar o índice em serviço é outra operação

A gestão de índices do MongoDB descreve um procedimento diferente para uma alteração normal de definição: o novo índice é construído em segundo plano enquanto o antigo continua atendendo consultas. Em mudanças de topologia, os novos nós são preparados antes da retirada dos anteriores. Existe alguém cobrindo o turno durante a troca.

A pausa elimina primeiro os dados dos nós de busca separados. A retomada parte dessa condição. Comprar a continuidade de uma atualização comum como se ela também cobrisse a volta da pausa é ler a promessa certa na operação errada. A empresa ganha clareza ao separar suspensão, mudança de definição e mudança de topologia no planejamento.

Para acompanhar a preparação, getSearchIndexes() retorna informações como estado e queryable, que indica se o índice pode receber consultas. Depois dessa checagem vem a prova do produto: a busca exigida pela aplicação encontra os registros esperados no tempo aceito? É esse resultado que autoriza a demonstração, o teste ou a retomada do trabalho.

Faltam medições de clientes que liguem tempo de reconstrução, busca útil e fatura; uma volta curta e previsível tornaria pausas frequentes mais atraentes. O mecanismo já permite uma conclusão firme: o desconto da suspensão vem acompanhado de uma reabertura. MongoDB cuida da obra automática. O comprador precisa terminar a conta depois de atender novamente.