Configurar Configurações Adicionais

Escolher uma Cadência de liberação

Você pode definir seus clusters do Atlas para seguir uma cadência de liberação principal ou uma cadência de liberaçã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 liberação MongoDB mais recente 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 se torna disponível. Durante a atualização para a próxima versão de lançamento rápido, o cluster na página Database Deployments da interface do usuário 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.

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ões do MongoDB no Manual MongoDB. Para obter mais detalhes sobre o Rapid Release, consulte Noções básicas sobre a API estável do MongoDB e a cadência rapid release.

Opções de backup de nível M2/M5

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

Opções de backup de nível M10+

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.

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

Sobre o sistema de fragmentação

O Atlas implementa cada fragmento como um conjunto de réplica de três nós, onde cada nó implementa utilizando o Cloud Provider & Region, Cluster Tier e Additional Settings configurado. 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.

Sobre os sistemas de servidores de configuração

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 as 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.

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.

Sobre o sistema do mongos

O Atlas implementa um roteador mongos para cada nó em cada shard. Para cluster entre regiões, isso permite que os clientes que usam um driver MongoDB se conectem ao mongos geograficamente mais próximo de .

Para calcular o número de roteadores do mongos em um agrupamento, multiplique o número de fragmentos pelo número de nós de conjunto de réplica 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.

Configurar o número de fragmentos

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

Você pode configurar o número de fragmentos a serem implementados com o cluster fragmentado. Seu cluster pode ter entre 1 e 50 fragmentos, inclusive.

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.

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.

Consideração para atualizar um conjunto de réplicas para um cluster fragmentado

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.

Quando a atualização for concluída, você deverá reiniciar todos os clientes de aplicativos e reconectar-se ao cluster fragmentado. 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ê estiver utilizando uma connection string Lista de sementes DNS , seu aplicativo se conectará automaticamente ao mongos para o cluster fragmentado.

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

Preferências de leitura

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

Configurações de amostragem

O Connector BI gera um esquema relacional por amostragem de dados do MongoDB. Você pode definir as seguintes configurações de amostragem:

Pré-requisitos

• Você deve configurar o projeto do Atlas para Encryption at Rest usando o Gerenciamento de Chaves antes de habilitar a funcionalidade para seus clusters do Atlas. Para saber mais, consulte Encryption at Rest usando o Gerenciamento de Chaves do Cliente.

• Para alternar de um fornecedor de encryption at rest no cluster para outro, você deve primeiro desabilitar a encryption at rest e, em seguida, reabilitá-la com o fornecedor desejado. Para saber mais, consulte Encryption at rest usando o Gerenciamento de chaves do cliente.

Procedimento

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.

O Atlas Encryption at Rest usando o Gerenciamento de Chaves está disponível para clusters de conjuntos de réplicas M10+. O Atlas Encryption at Rest oferece suporte somente à criptografia. Faça backup do seu sistema de banco de dados . Você não pode habilitar o encryption at rest em um cluster usando backups legados (obsoletos).

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.

Considerações

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?

Visualizar e editar configurações adicionais

Para visualizar e editar estas configurações:

Definir janela de oplog mínima

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 de arquivo de configuração do storage.oplogMinRetentionHours para cada mongod no agrupamento.

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 de oplog por 24 horas antes que o mongod as remova do oplog.

Definir tamanho do oplog

Você pode querer definir um tamanho fixo de oplog. Por exemplo, isso é útil durante a migração live 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. O Atlas habilita o auto-scaling de armazenamento por padrão.

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 do oplog:

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 e o tempo atuais do oplog.

Para definir um tamanho de oplog fixo:

1. Desative o dimensionamento automático de armazenamento.

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

3. Especifique o Oplog Size desejado em megabytes na caixa de entrada.

   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 de arquivo de configuração do replication.oplogSizeMB para cada mongod no agrupamento.

   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.

Aplicar limite de chave de índice

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. Esta opção corresponde à modificação do parâmetro param.failIndexKeyTooLong via o comando setParameter para cada mongod no cluster.

Permitir JavaScript no servidor

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 a 5.0, essa opção corresponde à modificação da opção de arquivo de configuração security.javascriptEnabled para cada mongod no cluster.

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

Habilitar registro de dados de query editados e anônimos

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.

Definir versão mínima do protocolo TLS

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

Exigir índices para todas as queries

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

Write concern padrão

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

MongoDB 5. Os clusters 0 são padronizados como 1.

Começando com MongoDB 5.0, a write concern padrão para cluster é a maioria.

Definir a vida útil da transação

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

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

Definir simultaneidade de migração de blocos

Para clusters Atlas fragmentados que executam o MongoDB versão 5.0.15 ou 6.0.6 e versões superiores, você pode definir o número de threads na origem e receber shard para melhorar o desempenho da migração de chunk. Você pode definir o valor para ser a metade do total de núcleos da CPU. Para saber mais, consulte chunkMigrationConcurrency.

Ativar ou desativar o pré-aquecimento de disco rápido

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

Para desabilitar o pré-aquecimento de disco rápido para um cluster, alterne 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 de 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 de disco está habilitado, 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 volumes de trabalho que buscam garantias de disponibilidade máxima sobre o desempenho consistente da query e exigir 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. O uso dessa string de conexão evita leituras no nó enquanto a maioria de seusIOPS é utilizada pelo processo de pré-aquecimento.