Menu Docs
Página inicial do Docs
/
MongoDB Atlas
/ /

Configurar Configurações Adicionais

Nesta página

Você pode definir as seguintes configurações adicionais para seu cluster Atlas.

O Atlas permite a criação de clusters com os seguintes níveis e versões MongoDB:

Versão do MongoDB
Compatível com M10+
Suportado em camadas gratuitas e compartilhadas (M0, M2, M5)

MongoDB 5.0

MongoDB 6.0

MongoDB 7.0

Versão mais recente (atualizações automáticas)

Importante

Se o seu cluster executar um release candidate do MongoDB, o Atlas atualizará o cluster para a versão de lançamento estável quando estiver disponível para o público geral.

Para usar uma versão de Rapid Release do MongoDB, você deve selecionar Latest Release para atualizações automáticas. Não é possível selecionar uma versão de Rapid Release específica.

À medida que novas versões de patch são disponibilizadas, o Atlas é atualizado para essas versões por meio de um processo contínuo para manter a disponibilidade do cluster. Durante a atualização para a próxima versão do Rapid Release, o cartão de cluster na página Database Deployments da IU do Atlas pode mostrar o FCV do seu cluster em vez da versão do MongoDB para refletir os recursos que estão disponíveis atualmente no seu cluster.

Para saber mais sobre como o Atlas lida com o fim da vida útil das principais versões do MongoDB, consulte O que acontece com os clusters do Atlas que usam uma versão do MongoDB que está chegando ao fim da vida útil?

Importante

Para selecionar a versão MongoDB para seu cluster, use o menu suspenso na seção Additional Settings do formulário de cluster.

Você pode atualizar um Atlas cluster existente para uma versão principal mais recente do MongoDB, se disponível, ao escalar um cluster. No entanto, você não pode fazer downgrade de um cluster de uma versão principal para uma versão principal anterior.

Importante

Se o projeto tiver uma função personalizada que utilize ações introduzidas em uma versão MongoDB específica, você não poderá criar um cluster com uma versão MongoDB inferior, a não ser que você exclua a função personalizada.

Você pode definir seus clusters do Atlas para seguir uma cadência de versão principal ou uma cadência de versão rápida.

Os clusters de nível gratuito e compartilhado devem seguir uma cadência de liberação principal. Você pode configurar um cluster de nível dedicado para seguir uma cadência de liberação principal, selecionando uma versão específica do MongoDB no menu suspenso na seção Additional Settings do formulário de cluster.

O Atlas não atualiza clusters automaticamente na cadência de lançamento principal. Você deve agendar uma atualização manual para cada novo lançamento principal à medida que ela entra em disponibilidade geral.

Você pode configurar um cluster de nível dedicado para seguir uma cadência de rapid release selecionando Latest Release no menu suspenso na seção Additional Settings de formulário do cluster.

Você pode configurar um cluster para versões rápidas somente se ele estiver executando a versão principal mais recente do MongoDB. Se o cluster estiver executando uma versão principal anterior, atualize manualmente para a versão principal mais recente para permitir a transição para a versão rápida.

O Atlas usa a versão mais recente do MongoDB para clusters que seguem a cadência de Rapid Release. O Atlas atualiza automaticamente esses clusters para as novas versões principais e de Rapid Release por meio de um processo contínuo para manter a disponibilidade do cluster à medida que cada versão fica disponível. Durante a atualização para a próxima versão do Rapid Release, o cluster na página Clusters da IU do Atlas pode mostrar o FCV do seu cluster em vez da versão do MongoDB para refletir os recursos atualmente disponíveis no seu cluster.

Observação

Se você mudar um cluster da versão principal para a cadência de rapid release, ele será atualizado diretamente para o rapid release atualmente disponível. Por exemplo, se o MongoDB 6.2 for o rapid release mais recente e você configurar um cluster executando 6.0 para rapid release, ele será atualizado diretamente para o MongoDB 6.2

Você pode reverter um cluster que segue a cadência de liberação rápida para a cadência de liberação principal, selecionando a versão principal mais recente no menu suspenso Select a Version. No entanto, você só pode fazer isso antes que a primeira rapid release do ano esteja disponível. Após a atualização de um cluster de uma liberação principal para uma rapid release, não é possível reverter até a próxima liberação principal.

Para saber mais sobre as versões do MongoDB, consulte Versão do MongoDB no Manual do MongoDB. Para obter mais detalhes sobre o Rapid Release, consulte Noções básicas sobre a Stable API do MongoDB e a cadência rapid release.

Esta seção descreve as opções de configuração da cópia de segurança para seu agrupamento do Atlas.

O Atlas habilita automaticamente M5 para M2 compartilhados e você não pode desabilitá-los. Para saber mais, consulte Backups de Cluster Compartilhados.

Para habilitar cópias de segurança para um cluster do Atlas M10+, alterne Turn on Backup (M10 and up) para Yes. Se ativado, o Atlas tira snapshots de seus bancos de dados em intervalos regulares e os retém de acordo com a política de retençãodo seu projeto.

Observação

Se você tiver uma Política de Conformidade de Backup habilitada, não poderá desabilitar o Backup em Nuvem. Não é possível desativar o backup contínuo na nuvem se a política de conformidade de backup tiver a opção Require Point in Time Restore to all clusters definida como On sem suporte ao MongoDB. Para desativar o backup em nuvem contínuo, o representante legal ou de segurança especificado para a Política de Conformidade de Backup deve solicitar suporte e concluir um extenso processo de verificação.

O Atlas fornece as seguintes opções de backup para clusters do M10+ :

Opção de backup
Descrição

O Atlas tira snapshots incrementais dos dados em seu cluster e permite restaurar os dados desses snapshots. O Atlas armazena snapshots na mesma região do fornecedor de nuvem que o membro do conjunto de réplicas direcionado para snapshots.

Depois que o Atlas restaura um snapshot, o Atlas reproduz o oplog para restaurar um cluster de um determinado ponto no tempo dentro de uma janela especificada na política de backup.

Para habilitar o Termination Protection para um agrupamento, alterne Termination Protection para Yes.

Se ativado, o Atlas impede que os usuários excluam o cluster. Para excluir um cluster que tenha a proteção contra encerramento ativada, primeiro você deve desabilitar a proteção contra encerramento. Por padrão, o Atlas desativa a proteção contra encerramento para todos os clusters.

Para saber mais sobre como encerrar o cluster, consulte Encerrar um sistema.

Dica

Você pode configurar o Arquivo Online para mover os dados raramente acessados do seu agrupamento do Atlas para uma instância do banco de dados federado somente para leitura gerenciado pelo MongoDB em vez de compartilhar sua coleção ou atualizar sua camada de agrupamento. Para saber mais sobre o arquivo online, consulte Gerenciar arquivos online.

Para implantar seu agrupamento como um aglomerado compartilhado, alterne Shard your cluster (M30 and up) para Yes.

Os clusters fragmentados permitem dimensionamento horizontal e consistem em fragmentos, servidores de configuração e roteadores mongos. Para saber mais, consulte Sobre a implantação de servidores de configuração. Os servidores de configuração devem permanecer legíveis para que as operações de leitura fragmentadas continuem funcionando.

Se você habilitar servidores de configuração gerenciados pelo Atlas, o Atlas poderá colocar os dados do servidor de configuração com os dados do aplicativo em vez de usar um servidor de configuração dedicado. Para saber mais, consulte Servidores de configuração autogerenciados para clusters fragmentados.

O Atlas implementa cada fragmento como um conjunto de réplica de três nós, em que cada nó implementa utilizando o Cloud Provider & Region, Cluster Tier e Additional Settings configurados. O Atlas implementa um mongod por nó de fragmento.

Para clusters entre regiões, o número de nós por fragmento é igual ao número total de nós apenas para leitura e elegíveis em todas as regiões configuradas. O Atlas distribui os nós de fragmentação nas regiões selecionadas.

Para servidores de configuração dedicados, o Atlas distribui os servidores de configuração como um conjunto de réplicas de três nós. Os servidores de configuração são executados em camadas do cluster M30. Em clusters multirregionais, os servidores de configuração são distribuídos entre regiões.

Para clusters entre regiões, o Atlas distribui os nós do conjunto de réplicas do servidor de configuração para garantir a disponibilidade ideal. Por exemplo, o Atlas pode distribuir os servidores de configuração em três zonas de disponibilidade distintas e três regiões diferentes, caso seja suportado pelo fornecedor de serviços na nuvem selecionado e pela configuração de região. Os servidores de configuração devem permanecer legíveis para que as operações de leitura fragmentadas continuem funcionando. Para saber mais, consulte Disponibilidade do servidor de configuração.

Se você habilitar servidores de configuração gerenciados pelo Atlas, o Atlas poderá colocar os dados do servidor de configuração com os dados do aplicativo em vez de usar um servidor de configuração dedicado. Para saber mais, consulte Servidores de configuração autogerenciados para clusters fragmentados.

Uma interrupção regional ou simulação de interrupção regional que afeta as regions de priority mais alta em um cluster fragmentado pode fazer com que o cluster se torne inoperável para priority de leitura. Para restaurar os servidores de configuração, faça o seguinte:

  • Configure uma preferência de leitura adequada para consultar nós secundários para leituras.

  • Reconfigure o cluster para recuperar os nós elegíveis.

O Atlas implementa um roteador mongos para cada nó em cada fragmento. Em clusters entre regiões, isso permite que os clientes que usam um driver do MongoDB se conectem ao mongos mais próximo em termos geográficos.

Para calcular o número de roteadores do mongos em um cluster, multiplique o número de fragmentos pelo número de nós de conjunto de réplicas por fragmento.

Você não pode converter um sistema de cluster fragmentado para uma sistema de conjunto de réplicas.

Para saber mais sobre como o número de instâncias do servidor afeta o custo, consulte Número de nós.

Para saber mais sobre clusters sharded, consulte Sharding no manual do MongoDB.

Este campo estará visível apenas se o sistema for um cluster fragmentado.

Seu cluster pode ter entre 1 e 70 fragmentos, inclusive.

Para escalar um conjunto de réplicas para um cluster com vários shards, você deve primeiro escalar para um cluster de único shard, reiniciar seu aplicativo e reconectar-se ao cluster, e então adicionar shards adicionais.

Se você não se reconectar os clientes do aplicativo, seu aplicativo poderá sofrer interrupções de dados.

Depois de dimensionar um cluster de conjunto de réplicas para um cluster de fragmento único, você pode definir o número de fragmentos a serem implantados com o cluster fragmentado.

Se você estiver reduzindo o número de fragmentos em seu cluster fragmentado, o Atlas removerá os fragmentos em ordem decrescente com base no número no campo "_id" (consulte Configuração de cluster fragmentado). Por exemplo, considere um cluster fragmentado com os seguintes três fragmentos:

  • "shard0"

  • "shard1"

  • "shard2"

Se você definir o número de fragmentos para dois, o Atlas removerá "shard2" do agrupamento.

Importante

Quando você remove um fragmento, o Atlas utiliza o comando movePrimary para mover quaisquer bancos de dados não compartilhados neste fragmento para um fragmento restante.

Todas as coleções fragmentadas permanecem online e disponíveis durante o processo de remoção de fragmentos. No entanto, as operações de leitura e escrita para coleções não fragmentadas durante a movePrimary operação pode resultar em comportamento inesperado, incluindo falha de migração ou perda de dados.

Recomendamos mover o fragmento primário para quaisquer bancos de dados que contenham coleções não compartilhadas antes de remover o fragmento.

Para obter mais informações, consulte Remover fragmentos de um cluster compartilhado existente.

Não crie um cluster fragmentado com um único fragmento para ambientes de produção. Os clusters de fragmentos únicos não fornecem os mesmos benefícios que as configurações de vários fragmentos. Depois de criar um cluster de fragmento único, reinicie o aplicativo, reconecte-se ao cluster e, em seguida, adicione mais fragmentos ao cluster.

Se a camada do cluster for M30 ou superior, você poderá atualizar o sistema de conjunto de réplicas para um sistema de cluster fragmentado.

Para escalar um conjunto de réplicas para um cluster com vários shards, você deve primeiro escalar para um cluster de único shard, reiniciar seu aplicativo e reconectar-se ao cluster, e então adicionar shards adicionais.

Se você não reiniciar os clientes do aplicativo, seus dados poderão ficar inconsistentes quando o Atlas começar a distribuir os dados entre os fragmentos.

Se você não se reconectar os clientes do aplicativo, seu aplicativo poderá sofrer interrupções de dados.

  • Se você estiver usando uma string de conexão de Lista de sementes DNS, seu aplicativo se conectará automaticamente ao mongos de seu cluster fragmentado.

  • Se você estiver usando uma cadeia de conexão padrão, deverá atualizar sua cadeia de conexão para refletir sua nova topologia de cluster.

Importante

O Atlas BI Connector está chegando ao fim da vida útil. Ele se tornará obsoleto e não será mais compatível em 2025 de junho.

O MongoDB está fazendo a transição do BI Connector for Atlas para Atlas SQL. Para saber mais sobre a transição para a nova interface, consulte Transição do Atlas BI Connector para Atlas SQL.

Para habilitar o BI Connector for Atlas para esse cluster, alterne Enable Business Intelligence Connector (M10 and up) para Yes.

Observação

O MongoDB Connector for Business Intelligence for Atlas (BI Connector) só está disponível para clusters M10 e maiores.

O BI Connector é uma ferramenta poderosa que oferece aos usuários acesso baseado em SQL a seus bancos de dados MongoDB . Como resultado, o BI Connector executa operações que podem ser intensivas em CPU e memória. Devido aos recursos limitados de hardware em M10 e camadas do cluster M20, pode ocorrer uma degradação do desempenho do cluster ao ativar o BI Connector. Se isso ocorrer, amplie para um cluster M30 ou maior ou desative o BI Connector.

Se habilitado, selecione o tipo de nó a partir do qual o Connector BI deve ler para o Atlas.

A tabela a seguir descreve as preferências de leitura disponíveis para o BI Connector e suas opções correspondentes de cadeia de conexão readPreference e readPreferenceTag.

Read Preference do Connector BI
Descrição
readPreference
readPreferenceTags

Principal

Ler do nó primário.

primary

none

secundário

Leia a partir de nós secundários.

secondary

{ nodeType : ELECTABLE } ou { nodeType : READ_ONLY }

Análise

Leia a partir dos nós de analítica.

secondary

{ nodeType : ANALYTICS }

A tag de preferência de leitura nodeType determina o tipo de nó ao qual o Conector de BI para Atlas se conecta. Você pode especificar os seguintes valores para esta opção:

  • ELECTABLE restringe o BI Connector aos nós primários e secundários elegíveis.

  • READ_ONLY restringe o BI Connector a se conectar a nós secundários não selecionáveis.

  • ANALYTICS restringe o connector BI a se conectar a nós de análise.

    Dica

    Quando você usa a preferência de leitura Analytics, o Atlas coloca o connector BI for Atlas no mesmo hardware que os nós de análise dos quais o connector BI for Atlas lê.

    Ao isolar nós portadores de dados elegíveis do connector BI para o Atlas, os nós elegíveis não competem por recursos com o connector BI para o Atlas, melhorando assim a confiabilidade e o desempenho do cluster.

Para ambientes de produção de alto tráfego, conectar-se ao Secondary Node(s) ou Analytics Node(s) pode ser preferível ao se conectar ao Primary Node.

Para clusters com um ou mais nós de análise, selecione Analytics Node para isolar as queries do BI Connector for Atlas de sua carga de trabalho operacional e ler a partir de nós de análise dedicados e somente leitura. Com essa opção, os nós elegíveis não competem por recursos com o BI Connector para Atlas, melhorando assim a confiabilidade e o desempenho do cluster.

Para gerar um esquema relacional, o BI Connector requer amostragem de dados do MongoDB.

Não é possível usar um arquivo .drdl ou usar o comando mongodrdl para substituir o estágio de amostragem no Atlas BI Connector.

Você pode definir as seguintes configurações de amostragem:

Opção de connector BI
Tipo
Descrição

Tamanho da amostra do esquema

inteiro

Opcional. O número de documentos que o BI Connector testa para cada banco de dados ao coletar informações de esquema. Para saber mais, consulte a documentação do BI Connector.

Intervalo de atualização da amostra

inteiro

Opcional. A frequência, em segundos, na qual o BI Connector re-sample data para recriar o esquema. Para saber mais, consulte a documentação do BI Connector.

Observação

Esta funcionalidade não está disponível para M0 clusters gratuitos e clusters flexíveis. Para saber mais sobre quais funcionalidades não estão disponíveis, consulte os Limites do Atlas M0 (cluster gratuito), M2 e M.5

O Atlas criptografa todo o armazenamento do cluster e os volumes de snapshots, garantindo a segurança de todos os dados em repouso (criptografia em descanso) do cluster. O Project Owners Atlas pode configurar uma camada adicional de criptografia em seus dados em repouso usando o mecanismo de armazenamento criptografado do MongoDB e seu provedor de criptografia em repouso compatível com Atlas.

O Atlas oferece suporte aos seguintes fornecedores de Encryption at Rest:

Para começar a gerenciar suas próprias chaves de encriptação para esse cluster, alterne de Encryption using your Key Management (M10 and up) para Yes.

A criptografia em repouso do Atlas que usa seu gerenciamento de chaves está disponível para clusters de conjuntos de réplicas M10+. A criptografia em repouso do Atlas é compatível apenas com Back Up Your Cluster.

Gerenciar suas próprias chaves de criptografia gera um aumento nos custos de execução por hora de seus clusters. Para saber mais sobre o faturamento do Atlas para funcionalidades avançadas de segurança, consulte Segurança avançada.

Importante

Se o Atlas não conseguir acessar o provedor de gerenciamento de chaves do projeto Atlas ou a chave de encriptação usada para criptografar um cluster, esse cluster se tornará inacessível e irrecuperável. Tenha muito cuidado antes de modificar, excluir ou desativar uma chave de encriptação ou as credenciais do provedor de gerenciamento de chaves que o Atlas usa.

Você pode configurar as seguintes opções de tempo de execução mongod em clusters de nível pago M10+.

Atlas modifica dinamicamente o Oplog Size para conjuntos de réplica e clusters fragmentados. No entanto, para as configurações Minimum TLS Protocol Version e Allow Server-Side JavaScript, ele executa uma reinicialização contínua dos membros do fragmento e do conjunto de réplicas do servidor de configuração. Para saber mais sobre como o Atlas suporta alta disponibilidade durante operações de manutenção, consulte Como o MongoDB Atlas oferece alta disponibilidade?

Para visualizar e editar estas configurações:

Para atualizar as definições de configuração avançadas para um cluster utilizando o Atlas CLI, execute o seguinte comando:

atlas clusters advancedSettings update <clusterName> [options]

Para saber mais sobre a sintaxe e os parâmetros do comando, consulte a documentação do Atlas CLI para clusters do Atlas advancedSettings update.

Dica

Veja: links relacionados

Para exibir e editar essas configurações com a IU do Atlas, abra o More Configuration Options em Additional Settings no formulário de cluster.

Modificar a duração da retenção para entradas de oplog no oplog do cluster. Por padrão, o Atlas retém as entradas por 24 horas antes que o mongod as remova do oplog.

Esta opção corresponde à modificação da opção do arquivo de configuração storage.oplogMinRetentionHours para cada mongod no cluster.

Para definir a janela de oplog mínima:

  1. Verifique se o auto-scaling de armazenamento está ativado e se você não desativou esse recurso. O Atlas habilita o auto-scaling por padrão.

  2. Defina a oplog window mínima para o valor desejado. Se você não definir esse valor, o Atlas reterá as entradas do oplog por 24 horas antes que o mongod as remova do oplog.

Você pode definir um tamanho fixo de oplog, o que é útil durante a migração em produção ou durante uma carga intensiva de dados.

Você pode definir a configuração do Set Oplog Size somente se optar por não usar o dimensionamento automático de armazenamento do cluster.

Para clusters que têm o dimensionamento automático de armazenamento ativado, você pode definir o Minimum Oplog Window. Consulte Definir oplog window mínima. Por padrão, o Atlas permite o dimensionamento de armazenamento.

O tamanho mínimo do oplog que você pode definir é 990 megabytes. O Atlas retornará um erro se o tamanho do oplog escolhido deixar o disco do cluster com menos de 25% de sua capacidade livre.

Para verificar o tamanho atual do oplog e o tempo de atraso da replicação:

  1. Conecte-se ao seu cluster via mongosh.

  2. Autenticar como um usuário com a função Atlas admin.

  3. Execute o método rs.printReplicationInfo().

O Atlas exibe o tamanho atual do oplog e o tempo de atraso da replicação.

Para definir um tamanho de oplog fixo:

  1. Desative o dimensionamento automático de armazenamento.

  2. Defina a Janela de Oplog Mínima como 0.

  3. Determinar o tamanho do oplog de que você precisa:

    • Monitore o tempo de atraso durante o processo de migração na IU do Atlas .

    • Se o tempo de atraso mostrado na UI do Atlas durante a migração se aproximar do tempo de atraso de replicação obtido usando o método rs.printReplicationInfo(), aumente o tamanho do oplog.

  4. Especifique o Oplog Size desejado em megabytes na caixa de entrada. Essa configuração define o tamanho descompactado do oplog, não o tamanho no disco.

    Para sistemas de cluster fragmentado, esta opção modifica o tamanho do oplog de cada shard no cluster.

    Esta opção corresponde à modificação da opção do arquivo de configuração replication.oplogSizeMB para cada mongod no cluster.

    Aviso

    Reduzir o tamanho do oplog requer a remoção de dados do mesmo. O Atlas não pode acessar ou restaurar quaisquer entradas do oplog removidas devido à redução do oplog. Considere as implicações dessa perda de dados antes de reduzir o oplog.

Não reduza o tamanho do oplog para aumentar o espaço em disco disponível. Somente a collection de oplog (local.oplog.rs) pode recuperar o espaço que reduzir o tamanho do oplog economiza. Outras collections não se beneficiam da redução do armazenamento de oplog.

Habilite ou desabilite a imposição do limite de chave de índice de 1024 bytes. Os documentos só poderão ser atualizados ou inseridos se, para todos os campos indexados na coleção de destino, as entradas de índice correspondentes não excederem 1024 bytes.

Se desativado, mongod grava documentos que ultrapassam o limite, mas não os indexa. Essa opção corresponde à modificação do parâmetro param.failIndexKeyTooLong por meio do comando setParameter para cada mongod no cluster.

Importante

Limite da chave do índice

param.failIndexKeyTooLong foi preterido na versão 4.2 do MongoDB e foi removido na versão 4.4 e posteriores do MongoDB. Para MongoDB anterior a 4.2, defina este parâmetro como false.

Habilite ou desabilite a execução de operações que executam a execução de JavaScript no lado do servidor.

  • Se o seu cluster executar uma versão do MongoDB inferior à 5.0, essa opção corresponderá à modificação da opção do arquivo de configuração security.javascriptEnabled para cada mongod no cluster.

  • Se o seu cluster executar o MongoDB versão 5.0 ou posterior, essa opção corresponderá à modificação da opção do arquivo de configuração security.javascriptEnabled para cada mongod e mongos no cluster.

  • Se o seu cluster executar a versão do MongoDB 8.0, o Allow Server-Side JavaScript será desabilitado por padrão para melhorar a segurança e o desempenho. Esta opção corresponde à opção de arquivo de configuração security.javascriptEnabled para cada mongod e mongos no cluster.

Observação

No MongoDB versão 5.0 e posterior, security.javascriptEnabled também se aplica ao mongos.

Incluir saída do $queryStats editada e anônima nos registros do MongoDB. A saída $queryStats não contém literais ou valores de campo. Habilitar essa configuração pode afetar o desempenho do seu cluster.

Observação

Você pode habilitar o log de dados de consulta apenas para clusters Atlas que executam o MongoDB 7.1 ou posterior.

Defina a versão mínima de TLS que o cluster aceita para conexões de entrada. Esta opção corresponde à configuração da opção do arquivo de configuração net.tls.disabledProtocols para cada mongod no cluster.

Observação

Descontinuação do TLS 1.0

Se você está considerando esta opção como um método para habilitar a versão obsoleta do protocolo Transport Layer Security (TLS) 1.0, leia Quais versões de TLS o Atlas suporta? antes de prosseguir. A descontinuação do TLS 1.0 pelo Atlas melhora a segurança dos dados em trânsito e se alinha às melhores práticas do setor. Habilitar o TLS 1.0 para qualquer cluster do Atlas acarreta riscos de segurança. Considere ativar o TLS 1.0 apenas pelo tempo necessário para atualizar a pilha de aplicativos para dar suporte ao TLS 1.1 ou posterior.

Em uma lista de conjuntos de cifras, selecione qual será usado para as comunicações nó a nó e cliente para Atlas do seu cluster. A lista de cifras disponíveis dependerá da versão mínima de TLS do cluster.

Habilite ou desabilite a execução de queries que exigem uma verificação da coleção para retornar resultados. Esta opção corresponde à modificação do parâmetro notablescan por meio do comando setParameter para cada mongod no cluster.

Define o nível padrão de confirmação solicitado ao MongoDB para operações de gravação nesse cluster.

A partir do MongoDB 5.0, a preocupação de gravação padrão para clusters é a maioria.

Defina o tempo de vida máximo das transações com vários documentos . Esta opção corresponde à modificação do parâmetro transactionLifetimeLimitSeconds através do comando setParameter para cada mongod no cluster.

Importante

Não é possível definir a duração da transação para menos de um segundo.

O tempo de vida padrão da transação para clusters é de 60 segundos.

Para clusters do Atlas fragmentados que executam o MongoDB versão 5.0.15 ou 6.0.6 e versões superiores, é possível definir o número de threads na origem e no fragmento de recebimento para melhorar o desempenho da migração de partes. É possível definir o valor para metade do número total de núcleos da CPU.. Para saber mais, consulte a página chunkMigrationConcurrency.

Para ativar o pré-aquecimento rápido do disco para um cluster, alterne Allow Fast Disk Pre-Warming para Yes.

Para desabilitar o pré-aquecimento rápido do disco para um cluster, mude de Allow Fast Disk Pre-Warming para No.

Devido ao design da infraestrutura subjacente do provedor de nuvem, o pré-aquecimento do disco ocorre sempre que o Atlas precisa provisionar um novo nó em um cluster, como quando você adiciona um novo nó a uma região existente. O pré-aquecimento do disco usa temporariamente um nó secundário oculto.

O pré-aquecimento rápido do disco é mais rápido que o aquecimento do disco em segundo plano. Por padrão, o Atlas habilita o pré-aquecimento de disco rápido para sua implantação. Quando o pré-aquecimento do disco está ativado, o Atlas oculta o nó e isso impede que esse nó execute operações de leitura.

Considere as seguintes recomendações:

  • Se você tiver cargas de trabalho que buscam latência de consulta consistente, habilite essa configuração.

  • Se você tiver cargas de trabalho que buscam garantias de disponibilidade máxima sobre o desempenho consistente da query e precisar que o nó recém-adicionado ou substituído esteja imediatamente ativo e visível, desabilite essa configuração e use uma string de conexão personalizada com tags para o nó que passa por pré-aquecimento até que o processo de pré-aquecimento seja concluído. Usar essa string de conexão impede leituras no nó enquanto a maior parte das suas IOPS é utilizada pelo processo de pré-aquecimento.

Para clusters que executam o MongoDB versão 8.0+, você pode especificar o tempo limite máximo padrão em milissegundos de todas as operações de leitura para esses clusters. Isso protege seu banco de dados contra queries de longa duração não intencionais. Esta opção corresponde ao parâmetro de cluster defaultMaxTimeMS.

Modifique o modo de dimensionamento do conjunto de réplicas para seu cluster. Por padrão, o Atlas dimensiona os nós In Parallel By Workload Type, o que significa que o Atlas dimensiona sua análise em paralelo aos seus nós operacionais.

O Atlas também pode dimensionar um conjunto de réplicas com os modos In Parallel By Node Type e Sequential .

In Parallel By Node Type O modo é para cargas de trabalho grandes e dinâmicas que exigem redimensionamento frequente e imediato em camadas de cluster. Neste modo, o Atlas dimensiona seus nós elegíveis em paralelo com seus nós somente leitura e de análise. Essa é a estratégia de dimensionamento mais rápida, mas pode afetar a latência das cargas de trabalho ao realizar leituras secundárias extensas.

Sequential é para cargas de trabalho em estado estável e aplicativos que executam leituras secundárias sensíveis à latência, o que significa que o Atlas dimensiona todos os nós sequencialmente.

Ative esta opção para evitar o registro de informações potencialmente confidenciais em valores de campo. Para obter mais informações, consulte Supressão de log.

Uma reinicialização contínua é necessária para habilitar e desabilitar a supressão de log.

Ative ou desative o gerenciamento do Atlas do tipo de servidor de configuração para um novo cluster fragmentado. Um servidor de configuração gerenciado pelo Atlas alterna automaticamente o tipo de servidor de configuração com base em critérios para desempenho ideal e economia de custos. Se você não habilitar um servidor de configuração gerenciado pelo Atlas para um cluster fragmentado, o Atlas sempre usará um servidor de configuração dedicado para o cluster.

Para todos os clusters fragmentados do Atlas 8.0, os servidores de configuração gerenciados pelo Atlas são On por padrão. Para desabilitar os servidores de configuração gerenciados pelo Atlas, defina a alternância para Off. Se o cluster tiver menos de quatro fragmentos e servidores de configuração incorporados, desativar os servidores de configuração gerenciados pelo Atlas fará a transição imediata do cluster para servidores de configuração dedicados.

Para cada novo cluster fragmentado com servidores de configuração habilitados gerenciados pelo Atlas, o Atlas implanta um servidor de configuração incorporado para clusters com menos de quatro fragmentos e um servidor de configuração dedicado para clusters com mais de três fragmentos.

Os servidores de configuração incorporados colocam os dados do seu aplicativo com os dados de configuração em um fragmento de configuração. Os clusters de servidor de configuração incorporados custam menos porque usam menos recursos.

Os servidores de configuração dedicados usam um conjunto de réplicas de servidor de configuração dedicadas e separadas para os dados de configuração. Os dados do seu aplicativo não ficam junto aos dados de configuração para servidores de configuração dedicados. Os clusters de servidor de configuração dedicados custam mais porque usam um conjunto de réplicas adicional.

Para saber mais sobre considerações para tipos de servidor de configuração, consulte Considerações sobre servidores de configuração.

Se você habilitar servidores de configuração gerenciados pelo Atlas, o Atlas determinará o tipo de servidor de configuração de cluster inicial da seguinte forma:

  • Se a contagem de fragmentos de cluster for maior que três, o Atlas usará um servidor de configuração dedicado .

  • Se a contagem de fragmentos do cluster for três ou menos, o Atlas usará um servidor de configuração incorporado.

Quando você adiciona ou remove fragmentos com servidores de configuração gerenciados pelo Atlas ativados, o Atlas seleciona automaticamente o tipo de servidor de configuração do seu cluster fragmentado usando os mesmos critérios.

Todos os clusters com uma versão inferior ao MongoDB 8.0 usam um servidor de configuração dedicado.

O Atlas não alterará o tipo do seu servidor de configuração se você usar qualquer um dos seguintes recursos:

Se você tiver um cluster com mais de três fragmentos que não consegue fazer a transição para um servidor de configuração dedicado devido ao uso desses recursos, entre em contato com o suporte do MongoDB para alterar o tipo do servidor de configuração.

Se você habilitar servidores de configuração gerenciados pelo Atlas, as seguintes considerações se aplicam:

  • Para clusters executando o MongoDB 8.0 ou posterior, os IDs do conjunto de réplicas não refletem o tipo de dados armazenados no conjunto de réplicas.

    • Os conjuntos de réplicas que contêm o termo shard no ID do conjunto de réplicas podem armazenar dados de aplicação, dados de configuração ou ambos (por exemplo: atlas-abc123-shard-0).

    • Os conjuntos de réplicas que contêm o termo config em seu ID do conjunto de réplicas podem armazenar dados do aplicativo (por exemplo: atlas-abc123-config-0).

  • Você pode restaurar snapshots de um cluster com um servidor de configuração dedicado somente para um cluster que também use um servidor de configuração dedicado.

  • Você pode restaurar snapshots de um cluster com um servidor de configuração incorporado somente para um cluster que também use um servidor de configuração incorporado.

Voltar

Auto-Scaling