Parâmetros do MongoDB Server para uma implementação autogerenciada

Parâmetros de autenticação

authenticationMechanisms

Disponível para mongod e mongos.

Especifica a lista de mecanismos de autenticação que o servidor aceita. Defina isso como um ou mais dos valores a seguir. Se você especificar vários valores, use uma lista separada por vírgulas e sem espaços. Para obter descrições dos mecanismos de autenticação, consulte Autenticação em implantações autogerenciadas.

Valor	Descrição
SCRAM-SHA-1	RFC 5802 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-1.
SCRAM-SHA-256	RFC 7677 Mecanismo de Autenticação de Resposta de Desafio Salted padrão usando a função de hash SHA-256.
MONGODB-X509	Autenticação de certificado TLS/SSL do MongoDB.
GSSAPI (Kerberos)	Autenticação externa usando Kerberos. Esse mecanismo está disponível somente no MongoDB Enterprise.
PLAIN (LDAP SASL)	Autenticação externa usando LDAP. Você também pode utilizar o PLAIN para autenticar usuários do banco de dados. PLAIN transmite senhas em texto simples. Esse mecanismo está disponível apenas no MongoDB Enterprise.
MONGODB-OIDC	OpenID Connect é uma camada de autenticação construída sobre OAuth2.2 Esse mecanismo está disponível somente no MongoDB Enterprise.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para especificar ambos PLAIN e SCRAM-SHA-256 como os mecanismos de autenticação, utilize o seguinte comando:

mongod --setParameter authenticationMechanisms=PLAIN,SCRAM-SHA-256 --auth

awsSTSRetryCount

Alterado na versão 7.0: (Também a partir de 6.0.7 e 5.0.18)

Em versões anteriores, a autenticação AWS IAM tentou novamente somente quando o servidor retornou um erro HTTP 500.

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 2

Para implantações MongoDB usando credenciais AWS IAM ou variáveis de ambiente AWS IAM.

Número máximo de tentativas de autenticação AWS IAM após uma falha de conexão.

O exemplo a seguir define awsSTSRetryCount para 15 tentativas:

mongod --setParameter awsSTSRetryCount=15

Como alternativa, os exemplos a seguir usam o comando setParameter no mongosh::

db.adminCommand( { setParameter: 1, awsSTSRetryCount: 15 } )

clusterAuthMode

Disponível para mongod e mongos.

Configure o clusterAuthMode para sendX509 ou x509. Útil durante a atualização contínua para usar o x509 para autenticação de associação a fim de minimizar o tempo de inatividade.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

Esse parâmetro só está disponível em tempo de execução. Para definir o parâmetro, use o comando setParameter.

db.adminCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )

enableLocalhostAuthBypass

Disponível para mongod e mongos.

Padrão: true

Especifique 0 ou false para desabilitar o desvio de autenticação localhost. Habilitado por padrão.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Consulte Exceção de localhost em implantações autogerenciadas para obter mais informações.

enforceUserClusterSeparation

Disponível para mongod e mongos.

Configure para false para desabilitar a verificação do O/OU/DC quando clusterAuthMode for keyFile em seu arquivo de configuração. Isto permite que clientes que possuem certificados de membro se autentiquem como usuários armazenados no banco de dados $external . O servidor não iniciará se clusterAuthMode não estiver keyFile em seu arquivo de configuração.

Para configurar o parâmetro enforceUserClusterSeparation para false, execute o seguinte comando durante a inicialização:

mongod --setParameter enforceUserClusterSeparation=false

Se você definir o parâmetro enforceUserClusterSeparation como false, o servidor não fará distinção entre certificados de cliente, que os aplicativos usam para autenticar, e certificados intra-cluster, que têm acesso privilegiado. Isso não terá efeito se o seu clusterAuthMode for keyFile. No entanto, se o seu clusterAuthMode for x509, os certificados de usuário que usam o esquema permitido serão confundidos com certificados de cluster e concedidos acesso privilegiado.

Seus certificados existentes receberão privilégios internos se você fizer o seguinte:

1. Crie um usuário, com um nome permitido por este parâmetro.

2. Configure o parâmetro enforceUserClusterSeparation para false.

3. Defina clusterAuthMode como x509.

Você não deve atualizar de keyFile para x509 sem validar que removeu usuários com privilégios elevados que o sinalizador enforceUserClusterSeparation lhe permitido criar.

KeysRotationIntervalSec

Disponível para mongod e mongos.

Padrão: 7776000 segundos (90 dias)

Especifica o número de segundos para os quais uma chave de assinatura HMAC é válida antes de girar para a próxima. Esse parâmetro tem como objetivo principal facilitar o teste de autenticação.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

ldapForceMultiThreadMode

Disponível apenas para mongod.

Padrão: false

Permite o desempenho de operações LDAP simultâneas.

Observação

Somente se você tiver certeza de que sua instância do libldap é segura para utilizar neste modo, habilite este sinalizador. Você pode enfrentar falhas no processo do MongoDB se a versão libldap que você estiver usando não for segura para threads.

Você deve utilizar o ldapForceMultiThreadMode para usar o pool de conexão LDAP. Para habilitar o pool de conexões LDAP, defina ldapForceMultiThreadMode e ldapUseConnectionPool como true.

Dica

Se tiver alguma dúvida sobre a versão do MongoDB, a versão do sistema operacional ou a versão da libldap, entre em contato com o Suporte do MongoDB.

ldapQueryPassword

Disponível apenas para mongod.

Tipo: string

A senha era vinculada a um servidor LDAP. Você deve usar ldapQueryUser com este parâmetro.

Se não estiver definido, o mongod ou o mongos não tentará se vincular ao servidor LDAP.

ldapQueryUser

Disponível apenas para mongod.

Tipo: string

O usuário que se liga a um servidor LDAP. Você deve usar ldapQueryPassword com esse parâmetro.

Se não estiver definido, o mongod ou o mongos não tentará se vincular ao servidor LDAP.

ldapRetryCount

Novidades na versão 6.1.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 0

Para implantações do MongoDB usando autorização LDAP em implantações autogerenciadas.

Número de tentativas de operação pelo gerenciador LDAP do servidor após um erro de rede.

Por exemplo, o seguinte define ldapRetryCount para 3 segundos:

mongod --ldapRetryCount=3

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, ldapRetryCount: 3 } )

ldapUserCacheInvalidationInterval

Alterado na versão 5.2.

Disponível apenas para mongod.

Observação

A partir do MongoDB 5.2, o intervalo de atualização das informações do usuário em cache recuperadas de um servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Se verdadeiro, utilize ldapUserCacheRefreshInterval.

• Se for falso, use ldapUserCacheInvalidationInterval.

Para uso com implantações do MongoDB usando autorização LDAP em implantações autogerenciadas.

O intervalo (em segundos) que a instância domongod aguarda entre as liberações de cache do usuário externo. Depois que o MongoDB libera o cache do usuário externo, o MongoDB readquire os dados de autorização do servidor LDAP na próxima vez que um usuário autorizado pelo LDAP emitir uma operação.

Aumentar o valor especificado aumenta a quantidade de tempo MongoDB e o servidor LDAP pode estar fora de sincronia, mas reduz a carga no servidor LDAP. Por outro lado, diminuir o valor especificado diminui o tempo que MongoDB e o servidor LDAP podem estar fora de sincronia enquanto aumenta o volume no servidor LDAP.

O padrão é 30 segundos.

ldapUserCacheRefreshInterval

Novidades na versão 5.2.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 30 segundos

Observação

A partir do MongoDB 5.2, o intervalo de atualização das informações do usuário em cache recuperadas de um servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Se verdadeiro, utilize ldapUserCacheRefreshInterval.

• Se for falso, use ldapUserCacheInvalidationInterval.

Para implantações do MongoDB usando autorização LDAP em implantações autogerenciadas.

O intervalo em segundos que mongod espera antes de atualizar as informações do usuário em cache do servidor LDAP.

O intervalo máximo é de 86.400 segundos (24 horas).

Por exemplo, o seguinte define ldapUserCacheRefreshInterval para 4000 segundos:

mongod --setParameter ldapUserCacheRefreshInterval=4000

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, ldapUserCacheRefreshInterval: 4000 } )

ldapUserCacheStalenessInterval

Novidades na versão 5.2.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 90 segundos

Para implantações do MongoDB usando autorização LDAP em implantações autogerenciadas.

O intervalo em segundos em que mongod retém as informações do usuário LDAP em cache após a última atualização do cache.

Se mais de ldapUserCacheStalenessInterval segundos se passarem sem uma atualização bem-sucedida das informações do usuário do servidor LDAP, então mongod:

• Invalida as informações do usuário LDAP em cache.

• Não é possível autenticar novas sessões para usuários LDAP até que o mongod se conecte ao servidor LDAP e autorize o usuário LDAP.

• Autoriza todas as sessões existentes que usam usuários LDAP previamente autenticados se mongod não conseguir se conectar ao servidor LDAP. Quando mongod se reconecta ao servidor LDAP, mongod garante que os usuários LDAP estão autorizados corretamente.

O intervalo máximo é de 86.400 segundos (24 horas).

Por exemplo, o seguinte define ldapUserCacheStalenessInterval para 4000 segundos:

mongod --setParameter ldapUserCacheStalenessInterval=4000

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, ldapUserCacheStalenessInterval: 4000 } )

ldapUseConnectionPool

Disponível apenas para mongod.

Especifica se o MongoDB deve usar o pooling de conexões ao se conectar ao servidor LDAP para autenticação/autorização.

O MongoDB utiliza os seguintes valores padrão:

• verdadeiro no Windows.

• verdadeiro no Linux onde os binários MongoDB Enterprise estão ligados ao libldap_r.

• false no Linux onde os binários do MongoDB Enterprise estão vinculados a libldap.

Você só pode definir ldapUseConnectionPool durante a inicialização e não pode alterar essa configuração com o comando banco de dados setParameter.

ldapConnectionPoolUseLatencyForHostPriority

Disponível apenas para mongod.

Padrão: true

Um booleano que determina se o pool de conexões LDAP (consulte a página ldapUseConnectionPool) deve usar a latência dos servidores LDAP para determinar a ordem de conexão (da menor latência para a mais alta).

Você só pode definir ldapConnectionPoolUseLatencyForHostPriority durante a inicialização e não pode alterar essa configuração durante o tempo de execução com o comando setParameter do banco de dados.

ldapConnectionPoolMinimumConnectionsPerHost

Disponível apenas para mongod.

Padrão: 1

O número mínimo de conexões para manter aberto a cada servidor LDAP.

Você só pode definir ldapConnectionPoolMinimumConnectionsPerHost durante a inicialização e não pode alterar essa configuração durante o tempo de execução com o comando setParameter do banco de dados.

ldapConnectionPoolMaximumConnectionsPerHost

Disponível apenas para mongod.

Alterado a partir das versões do MongoDB 5.0.9 e 6.0.0 do MongoDB O valor padrão foi alterado para 2147483647. Nas versões anteriores, o padrão não estava definido.

Padrão: 2147483647

O número máximo de conexões para manter aberto a cada servidor LDAP.

Você só pode definir ldapConnectionPoolMaximumConnectionsPerHost durante a inicialização e não pode alterar essa configuração durante o tempo de execução com o comando setParameter do banco de dados.

ldapConnectionPoolMaximumConnectionsInProgressPerHost

Disponível apenas para mongod.

Alterado a partir das versões do MongoDB 5.0.9 e 6.0.0 do MongoDB O valor padrão foi alterado para 2. Nas versões anteriores, o padrão não estava definido.

Padrão: 2

O número máximo de operações de conexão em andamento para cada servidor LDAP.

Você só pode definir ldapConnectionPoolMaximumConnectionsInProgressPerHost durante a inicialização e não pode alterar essa configuração com o comando banco de dados setParameter.

ldapConnectionPoolHostRefreshIntervalMillis

Disponível apenas para mongod.

Padrão: 60000

O número de milissegundos entre verificações de integridade das conexões LDAP agrupadas.

Você só pode definir ldapConnectionPoolHostRefreshIntervalMillis durante a inicialização e não pode alterar essa configuração com o comando banco de dados setParameter.

ldapConnectionPoolIdleHostTimeoutSecs

Disponível apenas para mongod.

Padrão: 300

O número máximo de segundos que as conexões agrupadas a um servidor LDAP podem permanecer ociosas antes de serem fechadas.

Você só pode definir ldapConnectionPoolIdleHostTimeoutSecs durante a inicialização e não pode alterar essa configuração com o comando banco de dados setParameter.

ldapShouldRefreshUserCacheEntries

Novidades na versão 5.2.

Disponível apenas para mongod.

Tipo: booleano

Padrão: true

Para implantações do MongoDB usando autorização LDAP em implantações autogerenciadas.

A partir do MongoDB 5.2, o intervalo de atualização das informações do usuário em cache recuperadas de um servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Se verdadeiro, utilize ldapUserCacheRefreshInterval.

• Se for falso, use ldapUserCacheInvalidationInterval.

Você só pode definir ldapShouldRefreshUserCacheEntries durante a inicialização no configuration file ou com a opção --setParameter na linha de comando. Por exemplo, o seguinte desabilita ldapShouldRefreshUserCacheEntries:

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

maxValidateMemoryUsageMB

Disponível apenas para mongod.

Novidades na versão 5.0.

Padrão: 200

O limite máximo de uso de memória em megabytes para o comando validate . Se o limite for excedido, validate retornará tantos resultados quanto possível e avisará que nem todos os danos poderão ser relatados devido ao limite.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

oidcIdentityProviders

Disponível apenas para mongod.

Alterado na versão 8.0: (Também disponível em 7.3 e 7.0)

Use esse parâmetro para especificar as configurações do provedor de identidade (IDP) ao usar a autenticação do OpenID Connect.

oidcIdentityProviders aceita uma array de configurações de provedor de identidade (IDP) zero ou mais. Uma array vazia (padrão) indica que o suporte ao OpenID Connect não está habilitado.

Quando mais de um IDP é definido, o oidcIdentityProviders utiliza o campo matchPattern para selecionar um IDP. A ordem da array determina a prioridade e o primeiro IDP está sempre selecionado.

A partir do MongoDB 8.0, quando vários provedores de identidade (IDP) são definidos, o parâmetro oidcIdentityProviders aceita valores issuer duplicados, desde que o valor audience seja exclusivo para cada emitir. Isso também está disponível nas versões 7.3 e 7.0.

CamposoidcIdentityProviders

Campo	necessidade	Tipo	Descrição
issuer	Obrigatório	string	O URI do emissor do IDP do qual o servidor deve aceitar tokens. Isso deve corresponder ao campo iss em qualquer JWT usado para autenticação. A partir do MongoDB 8.0, quando vários fornecedores de identidade (IDP) são definidos, o parâmetro oidcIdentityProviders aceita valores issuer duplicados, desde que o valor audience seja exclusivo para cada emissor. Isso também está disponível nas versões 7.3 e 7.0. Se você especificar um URI de emissor inacessível, o MongoDB: Registra um aviso. Continua a inicialização do servidor, o que permite atualizar o URI do emissor. Tenta novamente fazer contato com o emissor. Se o MongoDB contatar o URI do emissor e validar o token de acesso, a autenticação será bem-sucedida. Se o URI do emissor permanecer inacessível, a autenticação falhará. Alterado na versão 8.0: (Também disponível em 7.3 e 7.0)
authNamePrefix	Obrigatório	string	Prefixo único aplicado para cada UserName e RoleName gerado utilizado na autorização. authNamePrefix só pode conter os seguintes caracteres: caracteres alfanuméricos (combinação de a a z e 0 a 9) hifens (-) sublinhados (_)
matchPattern	Condicional	string	Padrão regex usado para determinar qual IDP deve ser usado. matchPattern corresponde a nomes de usuários. A ordem da bandeja determina a prioridade e o primeiro IDP está sempre selecionado. matchPattern é necessário em algumas configurações, dependendo de como o usuário define o supportsHumanFlows: Quando somente um IdP tem supportsHumanFlows configurado para true (o padrão), matchPatterns é opcional. Quando múltiplos IdPs têm supportsHumanFlows configurado para true (o padrão), cada um destes exige matchPatterns. matchPatterns é opcional para qualquer IdP em que supportsHumanFlows está definido como false. Este não é um mecanismo de segurança. matchPattern serve apenas como aconselhamento aos clientes. O MongoDB aceita tokens emitidos pelo IDP cujos nomes principais não correspondem a esse padrão.
clientId	Condicional	string	ID fornecida pelo IDP para identificar o cliente que recebe os tokens de acesso. Obrigatório quando supportsHumanFlows está definido como true (o padrão).
audience	Obrigatório	string	Especifica o aplicativo ou serviço para o qual o token de acesso é destinado. A partir do MongoDB 7.0, somente um campo audience oidcIdentityProviders pode ser especificado para tokens de acesso do OIDC. Os campos audience com arrays vazios ou arrays de múltiplas strings são inválidos. Quando mais de um IDP é definido, esse deve ser um valor exclusivo para cada configuração que compartilha um issuer.
requestScopes	Opcional	array[ string ]	Permissões e níveis de acesso que o MongoDB solicita do IDP.
principalName	Opcional	string	A reivindicação a ser extraída do token de acesso contendo identificadores de usuário MongoDB. O valor padrão é sub (significa subject).
useAuthorizationClaim	Opcional	booleano	Determina se o authorizationClaim é necessário. O valor padrão é true. Se o campo useAuthorizationClaim estiver configurado para true, o servidor exigirá um authorizationClaim para a configuração do provedor de identidade. Este é o comportamento padrão. Se o campo useAuthorizationClaim estiver configurado para false, o campo authorizationClaim será opcional (e ignorado se fornecido). Em vez disso, o servidor faz o seguinte: Pesquisa no token uma reivindicação cujo nome esteja listado no campo principalNameClaim. Normalmente, esse nome é sub. Por exemplo: sub: "spencer.jackson@example.com" Constrói o nome de usuário interno concatenando o authNamePrefix, uma barra (/) e o conteúdo da reivindicação identificada por principalNameClaim no token de acesso. Por exemplo, com um valor de campo authNamePrefix de "mdbinc", o nome de usuário interno é: mdbinc/spencer.jackson@example.com Procura o usuário com este nome de usuário e autoriza o cliente com os roles: { user: "mdbinc/spencer.jackson@example.com", db: "$external" } Novidade na versão 7.2: (também disponível na versão 7.0.5)
authorizationClaim	Condicional	string	Necessário, a menos que useAuthorizationClaim esteja definido como false. Reclamação extraída do token de acesso que contém nomes de função MongoDB.
logClaims	Opcional	array[ string ]	Lista de reivindicações de token de acesso a serem incluídas em mensagens de registro e auditoria após a conclusão da autenticação.
JWKSPollSecs	Opcional	inteiro	Frequência, em segundos, para solicitar um JSON Web Key Set (JWKS) atualizado do IDP. Uma configuração de 0 desabilita a pesquisa. Quando mais de um IDP é definido, este deve ser o mesmo valor para cada configuração que compartilha um issuer.
supportsHumanFlows	Opcional	bool	Se o provedor OIDC oferece suporte a fluxos de trabalho humanos ou de máquina. Isso afeta os campos clientId e matchPattern. Pode ser útil definir esse campo como false com IdPs de carga de trabalho de máquina para permitir que eles omitam o clientId quando ele não for necessário. Padrão: true. Novidade na versão 7.2.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

ocspEnabled

Disponível para mongod e mongos.

Disponível no Linux e macOS.

Padrão: true

O sinalizador que habilita ou desabilita OCSP.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, o seguinte desativa o OCSP:

mongod --setParameter ocspEnabled=false ...

A partir do MongoDB 6.0, se ocspEnabled for definido como true durante a sincronização inicial, todos os nós deverão ser capazes de acessar o respondedor OCSP.

Se um membro falhar no estado STARTUP2, configure tlsOCSPVerifyTimeoutSecs para um valor menor que 5.

Dica

Veja também:

• ocspValidationRefreshPeriodSecs

• tlsOCSPStaplingTimeoutSecs

• tlsOCSPVerifyTimeoutSecs

ocspValidationRefreshPeriodSecs

Disponível para mongod e mongos.

Disponível no Linux.

O número de segundos de espera antes de atualizar a resposta de status do OCSP grampeada. Especifique um número maior ou igual a 1.

Você só pode definir ocspValidationRefreshPeriodSecs durante a inicialização no configuration file ou com a opção --setParameter na linha de comando. Por exemplo, o seguinte define o parâmetro com 3600 segundos:

mongod --setParameter ocspValidationRefreshPeriodSecs=3600 ...

A partir do MongoDB 5.0, o comando rotateCertificates e o método db.rotateCertificates() também atualizarão todas as respostas OCSP grampeadas.

Dica

Veja também:

• ocspEnabled

• tlsOCSPStaplingTimeoutSecs

• tlsOCSPVerifyTimeoutSecs

opensslCipherConfig

Disponível para mongod e mongos.

Disponível apenas no Linux

Com o uso de bibliotecas TLS/SSL nativas, o parâmetro opensslCipherConfig é suportado para Linux/BSD e não é mais suportado no Windows e macOS.

Especifique a string de cifra para OpenSSL ao usar criptografia TLS/SSL. Para obter uma lista de strings de cifra, consulte https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Várias strings de cifra podem ser fornecidas como uma lista separada por dois pontos.

Observação

Este parâmetro deve ser usado somente com TLS 1.2 ou anterior. Para especificar conjuntos de codificação para uso com TLS 1.3, use o parâmetro opensslCipherSuiteConfig.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

O uso de opções TLS é preferível a opções SSL. As opções TLS têm a mesma funcionalidade que as opções SSL . O exemplo a seguir configura um mongod com uma string de cifra opensslCipherConfig de 'HIGH:!EXPORT:!aNULL@STRENGTH':

mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL@STRENGTH' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem

opensslCipherSuiteConfig

Disponível para mongod e mongos.

Novidades na versão 5.0.

Disponível apenas no Linux

Especifique a lista de pacotes de criptografia suportados que o OpenSSL deve permitir ao usar a criptografia TLS 1.3.

Para obter uma lista de conjuntos de codificação para uso com TLS 1.3, consulte https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html. Vários conjuntos de cifras podem ser fornecidos como uma lista separada por dois pontos.

Observação

Este parâmetro deve ser usado somente com TLS 1.3. Para especificar strings de caracteres de codificação para uso com TLS 1.2 ou anterior, use o parâmetro opensslCipherConfig.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, o seguinte configura um mongod com um conjunto de cifras opensslCipherSuiteConfig de 'TLS_AES_256_GCM_SHA384' para uso com TLS 1.3:

mongod --setParameter opensslCipherSuiteConfig='TLS_AES_256_GCM_SHA384' --tlsMode requireTLS --tlsCertificateKeyFile Certs/server.pem

opensslDiffieHellmanParameters

Disponível para mongod e mongos.

Disponível apenas no Linux

Especifique o caminho para o arquivo PEM que contém os parâmetros OpenSSL Diffie-Hellman ao usar TLS 1.2 ou versão anterior. A especificação dos parâmetros OpenSSL Diffie-Hellman permite o suporte para conjuntos de cifras Ephemeral Diffie-Hellman (DHE) durante a criptografia TLS/SSL.

Este parâmetro não é suportado para uso com TLS 1.3.

Os conjuntos de cifras Diffie-Hellman (DHE) efêmero (e os conjuntos de cifras ECDHE (curva elíptica efêmera Diffie-Hellman)) fornecem sigilo de encaminhamento. os conjuntos de cifras com sigilo de encaminhamento criam uma chave de sessão efêmera que é protegida pela chave privada do servidor, mas nunca é transmitida. Isso garante que, mesmo que a chave privada de um servidor seja comprometida, você não poderá descriptografar sessões anteriores com a chave comprometida.

Observação

Se opensslDiffieHellmanParameters não estiver definido, mas o ECDHE estiver habilitado, o MongoDB ativará o DHE usando o parâmetro Diffie-Hellman ffdhe3072, conforme definido no Apêndice A.2 da RFC-7919. O ffdhe3072 é um parâmetro forte (especificamente, o tamanho é maior que 1024). Os parâmetros fortes não são compatíveis com o Java 6 e 7, a menos que você tenha comprado o suporte estendido da Oracle.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Se, para melhorar o desempenho, você precisar desabilitar o suporte para conjuntos de codificação DHE, use o parâmetro opensslCipherConfig:

mongod --setParameter opensslCipherConfig='HIGH:!EXPORT:!aNULL:!DHE:!kDHE@STRENGTH' ...

saslauthdPath

Disponível para mongod e mongos.

Observação

Disponível apenas no MongoDB Enterprise (exceto MongoDB Enterprise para Windows).

Especifique o caminho para o Soquete de Domínio Unix da instância do saslauthd para utilizar para autenticação proxy.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

saslHostName

Disponível para mongod e mongos.

saslHostName substitui a detecção de nome de host padrão do MongoDB com o objetivo de configurar a autenticação SASL e Kerberos.

saslHostName não afeta o nome do host da instância mongod ou mongos para nenhuma finalidade além da configuração do SASL e do Kerberos.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Observação

saslHostName suporta a autenticação Kerberos e está incluída apenas no MongoDB Enterprise. Para obter mais informações, consulte o seguinte:

• Linux: Configurar o MongoDB autogerenciado com autenticação Kerberos no Linux

• Windows: Configurar o MongoDB autogerenciado com autenticação Kerberos no Windows

saslServiceName

Disponível para mongod e mongos.

Permite que os usuários substituam o componente de nome de serviço Kerberos padrão do nome principal do Kerberos, por instância. Se não for especificado, o valor padrão será mongodb.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

saslServiceName está disponível apenas no MongoDB Enterprise.

Importante

Certifique-se de que seu driver ofereça suporte a nomes de serviço alternativos.

scramIterationCount

Disponível para mongod e mongos.

Padrão: 10000

Altera o número de iterações de hash usadas para todas as novas senhas do SCRAM-SHA-1. Mais iterações aumentam o tempo necessário para que os clientes autentiquem no MongoDB, mas tornam as senhas menos suscetíveis a tentativas de força bruta. O valor padrão é ideal para casos de uso e requisitos mais comuns.

Se você modificar este valor, ele não alterará a contagem de iteração para senhas existentes. O valor scramIterationCount deve ser 5000 ou maior.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o comando seguinte define o scramIterationCount como 12000.

mongod --setParameter scramIterationCount=12000

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, scramIterationCount: 12000 } )

Dica

Veja também:

• db.changeUserPassword()

• db.createUser()

• db.updateUser()

scramSHA256IterationCount

Disponível para mongod e mongos.

Padrão: 15000

Altera o número de iterações de hash usadas para todas as novas senhas do SCRAM-SHA-256. Mais iterações aumentam o tempo necessário para que os clientes autentiquem no MongoDB, mas tornam as senhas menos suscetíveis a tentativas de força bruta. O valor padrão é ideal para casos de uso e requisitos mais comuns.

Se você modificar esse valor, isso não alterará a contagem de iterações para senhas existentes. O valor scramSHA256IterationCount deve ser 5000 ou maior.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o comando seguinte define o scramSHA256IterationCount como 20000.

mongod --setParameter scramSHA256IterationCount=20000

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, scramSHA256IterationCount: 20000 } )

Dica

Veja também:

• db.changeUserPassword()

• db.createUser()

• db.updateUser()

sslMode

Disponível para mongod e mongos.

Configure o net.ssl.mode para preferSSL ou requireSSL. Útil durante a atualização de rolagem para TLS/SSL para minimizar o tempo de inatividade.

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

Esse parâmetro só está disponível em tempo de execução. Para definir o parâmetro, use o comando setParameter.

db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } )

Dica

Veja também:

tlsMode

tlsMode

Disponível para mongod e mongos.

Definir como:

• preferTLS

• requireTLS

O parâmetro tlsMode é útil durante a atualização contínua a TLS/SSL para minimizar o tempo de inatividade.

Esse parâmetro só está disponível em tempo de execução. Para definir o parâmetro, use o comando setParameter.

db.adminCommand( { setParameter: 1, tlsMode: "preferTLS" } )

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

Dica

Veja também:

sslMode

tlsClusterAuthX509Override

Disponível para mongod e mongos.

Novidades na versão 7.0.

Substitui as opções de configuração do clusterAuthX509.

setParameter:
   tlsClusterAuthX509Override: { attributes: O=MongoDB, OU=MongoDB Server }

O parâmetro suporta substituições attributes e extensionValue .

Quando o servidor autentica conexões de nós, ele analisa o certificado X.509 para determinar se ele pertence a um nó do cluster. Se o servidor usar a configuração attributes ou o campo attributes no parâmetro tlsClusterAuthX509Override , ele verificará os valores de DN (nome diferenciado) do certificado. Se a configuração extensionValue ou o campo extensionValue do parâmetro tlsClusterAuthX509Override estiverem definidos, ela verificará os valores da extensão do certificado. Se encontrar uma correspondência, autoriza a conexão como par.

Use este parâmetro para girar certificados quando os novos certificados tiverem atributos diferentes ou valores de extensão.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

tlsOCSPStaplingTimeoutSecs

Disponível para mongod e mongos.

Disponível para Linux.

O número máximo de segundos que a instância mongod / mongos deve esperar para receber a resposta de status do OCSP para seus certificados.

Especifique um número inteiro maior ou igual a (>=) 1. Se não for definido, tlsOCSPStaplingTimeoutSecs usa o valor tlsOCSPVerifyTimeoutSecs.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, o seguinte define o tlsOCSPStaplingTimeoutSecs para 20 segundos:

mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

Dica

Veja também:

• ocspEnabled

• ocspValidationRefreshPeriodSecs

• tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

Disponível para mongod e mongos.

Disponível para Linux e Windows.

Padrão: 5

O número máximo de segundos que o mongod / mongos deve aguardar a resposta OCSP ao verificar os certificados do servidor.

Especifique um número inteiro maior ou igual a (>=) 1.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, o seguinte define o tlsOCSPVerifyTimeoutSecs para 20 segundos:

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Dica

Veja também:

• ocspEnabled

• ocspValidationRefreshPeriodSecs

• tlsOCSPStaplingTimeoutSecs

tlsUseSystemCA

Disponível apenas para mongod.

Tipo: booleano

Padrão: false

Especifica se o MongoDB carrega certificados TLS que já estão disponíveis para a autoridade de certificação do sistema operacional.

Importante

Ao iniciar uma instância mongod com TLS/SSL habilitado, especifique um valor para o sinalizador --tlsCAFile, a opção de configuração net.tls.CAFile ou o parâmetro tlsUseSystemCA.

--tlsCAFile, tls.CAFile e tlsUseSystemCA são mutuamente exclusivos.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para definir tlsUseSystemCA como true:

mongod --setParameter tlsUseSystemCA=true

Para obter mais informações sobre TLS/SSL e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes.

tlsWithholdClientCertificate

Disponível para mongod e mongos.

Padrão: false

Um certificado TLS é definido para mongod ou mongos pela opção --tlsClusterFile ou pela opção --tlsCertificateKeyFile quando --tlsClusterFile não está definido. Se o certificado TLS estiver definido, por padrão, a instância enviará o certificado ao iniciar as comunicações dentro do cluster com outras instâncias mongod ou mongos na implantação. Defina tlsWithholdClientCertificate como 1 ou true para direcionar a instância a reter o envio do certificado TLS durante essas comunicações. Utilize esta opção com --tlsAllowConnectionsWithoutCertificates (para permitir conexões de entrada sem certificados) em todos os membros da implantação. tlsWithholdClientCertificate é mutuamente exclusivo com --clusterAuthMode x509.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

tlsX509ClusterAuthDNOverride

Disponível para mongod e mongos.

Um Nome Distinto (DN) alternativo que a instância também pode utilizar para identificar membros da implantação.

Para uma implantação do MongoDB que usa certificados x.509 para clusterAuthMode, os membros da implantação se identificam usando certificados x.509 (net.tls.clusterFile, se especificado e net.tls.certificateKeyFile) durante as comunicações intra-cluster. Para membros da mesma implantação, o DN de seus certificados deve ter os mesmos atributos da Organização (deO), os atributos da Unidade organizacional (de OU) e os componentes de domínio (de DC).

Se tlsX509ClusterAuthDNOverride estiver configurado para um membro, o membro também poderá utilizar o valor de substituição ao comparar os componentes DN (O, OU e DC) dos certificados apresentados. Ou seja, o membro compara os certificados apresentados com seu net.tls.clusterFile/net.tls.certificateKeyFile. Se o DN não corresponder, o membro verificará o certificado apresentado em relação ao valor tlsX509ClusterAuthDNOverride.

Observação

Se definido, você deve configurar este parâmetro em todos os membros da implantação.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Você pode usar esse parâmetro para uma atualização contínua de certificados para novos certificados que contenham um novo valor DN. Consulte Atualização contínua de Certificados x.509 que contêm novo DN em clusters autogerenciados.

Para obter mais informações sobre os requisitos de certificado de membro, consulte Requisitos de certificado de membro para obter detalhes.

tlsX509ExpirationWarningThresholdDays

Disponível para mongod e mongos.

Padrão : 30

mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias do relógio do sistema do mongod/mongos. Utilize o parâmetro tlsX509ExpirationWarningThresholdDays para controlar o limite de aviso de expiração do certificado:

• Aumente o valor do parâmetro para acionar avisos mais à frente da data de expiração do certificado.

• Diminuir o valor do parâmetro para acionar avisos mais próximos da data de expiração do certificado.

• Defina o parâmetro para 0 para desativar o aviso.

Este parâmetro tem um valor mínimo de 0.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Para obter mais informações sobre a validade do certificado x.509, consulte a RFC 5280 4.1.2.5.

userCacheInvalidationIntervalSecs

Disponível apenas para mongos.

Padrão: 30

Em uma instância mongos, especifica o intervalo (em segundos) no qual a instância mongos verifica se o cache na memória de objetos de usuário tem dados obsoletos e, em caso afirmativo, limpa o cache. Se não houver alterações nos objetos de usuário, mongos não limpará o cache.

Este parâmetro tem um valor mínimo de 1 segundo e um valor máximo de 86400 segundos (24 horas).

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

authFailedDelayMs

Disponível para mongod e mongos.

Padrão: 0

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

O número de milissegundos para aguardar antes de informar aos clientes que a tentativa de autenticação deles falhou. Este parâmetro pode estar no intervalo de 0 a 5000, inclusive.

A configuração deste parâmetro torna os ataques de login da força bruta em um banco de dados mais demorados. No entanto, os clientes que aguardam uma resposta do servidor MongoDB ainda consomem recursos do servidor, e isso pode afetar negativamente as tentativas de login benignas se o servidor estiver negando acesso a muitos outros clientes simultaneamente.

allowRolesFromX509Certificates

Disponível para mongod e mongos.

Padrão: true

Um sinalizador booleano que permite ou não a recuperação de funções de autorização de certificados x.509 do cliente.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Parâmetros gerais

allowDiskUseByDefault

Disponível apenas para mongod.

Padrão: Verdadeiro

A partir do MongoDB 6.0, os estágios do pipeline que exigem mais de 100 megabytes de memória para execução gravam arquivos temporários no disco por padrão. Esses arquivos temporários duram durante a execução do pipeline e podem influenciar o espaço de armazenamento na sua instância. Em versões anteriores do MongoDB, você deve passar { allowDiskUse: true } para find individuais e comandos aggregate para habilitar esse comportamento.

Comandos individuais find e aggregate podem substituir o parâmetro allowDiskUseByDefault por:

• Usando { allowDiskUse: true } para permitir a gravação de arquivos temporários no disco quando allowDiskUseByDefault estiver definido como false

• Usando { allowDiskUse: false } para proibir a gravação de arquivos temporários no disco quando allowDiskUseByDefault estiver definido como true

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

mongod --setParameter allowDiskUseByDefault=false

allowDiskUseByDefault só funciona em mongod e não mongos. mongos nunca grava arquivos temporários em disco. Use o comando setParameter em uma sessão mongosh que esteja conectada a um mongod em execução para alterar o valor do parâmetro enquanto o servidor estiver em execução:

db.adminCommand(
  {
      setParameter: 1,
      allowDiskUseByDefault: false
  }
)

httpVerboseLogging

Disponível para mongod e mongos.

Adiciona rastreamento mais detalhado para curl no Linux e macOS. Não afeta o Windows.

Por padrão, o parâmetro não está definido.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

mongos --setParameter httpVerboseLogging=true

slowConnectionThresholdMillis

Novidades na versão 6.3.

Disponível para mongod e mongos.

Padrão: 100

Define o limite de tempo em milissegundos para registrar o estabelecimento de conexões de servidor lentas.

Se uma conexão demorar mais para ser estabelecida do que o parâmetro slowConnectionThresholdMillis, um evento será adicionado ao log com o campo de mensagem msg definido como "Slow connection establishment".

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define slowConnectionThresholdMillis como 250 milissegundos.

mongod --setParameter slowConnectionThresholdMillis=250

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, slowConnectionThresholdMillis: 250 } )

connPoolMaxConnsPerHost

Disponível para mongod e mongos.

Padrão: 200

Define o tamanho máximo dos pools de conexão legados para conexões de saída com outras instâncias mongod no pool de conexão global. O tamanho de um pool não impede a criação de conexões adicionais, mas impede que um pool de conexões retenha conexões que excedam o valor de connPoolMaxConnsPerHost.

Observação

O parâmetro é separado das conexões em pools do TaskExecutor. Consulte ShardingTaskExecutorPoolMaxSize.

Só ajuste essa configuração se o driver não agrupar conexões e você estiver usando a autenticação no contexto de um cluster fragmentado.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

Disponível para mongod e mongos.

Define o número máximo de conexões em uso a qualquer momento para conexões de saída para outras instâncias mongod no pool de conexões globais herdado.

Por padrão, o parâmetro não está definido.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Dica

Veja também:

connPoolMaxConnsPerHost

globalConnPoolIdleTimeoutMinutes

Disponível para mongod e mongos.

Define o limite de tempo que a conexão no pool de conexões global herdado pode permanecer ociosa antes de ser fechada.

Por padrão, o parâmetro não está definido.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

cursorTimeoutMillis

Disponível para mongod e mongos.

Padrão: 600000 (10 minutos)

Define o limite de expiração em milissegundos para cursores ociosos antes que o MongoDB os remova; especificamente, o MongoDB remove cursores que ficaram ociosos para o cursorTimeoutMillis especificado.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o comando seguinte define cursorTimeoutMillis como 300000 milissegundos (5 minutos).

mongod --setParameter cursorTimeoutMillis=300000

Ou, se estiver usando o comando setParameter dentro de mongosh:

db.adminCommand( { setParameter: 1, cursorTimeoutMillis: 300000 } )

Definir cursorTimeoutMillis como menor ou igual a 0 faz com que todos os cursores se qualifiquem imediatamente para o tempo limite. Geralmente, o valor de tempo limite deve ser maior que o tempo médio para uma consulta retornar resultados. Use ferramentas como o modificador de cursor cursor.explain() para analisar o tempo médio de query e selecionar um período de tempo limite apropriado.

Aviso

O MongoDB limpa os cursores órfãos vinculados a sessões como parte do gerenciamento de sessões. Isso significa que os cursores órfãos com IDs de sessão não usam cursorTimeoutMillis para controlar o tempo limite.

Para operações que retornam um cursor e têm um período ocioso maior que localLogicalSessionTimeoutMinutes, utilize Mongo.startSession() para executar a operação dentro de uma sessão explícita. Para atualizar a sessão, execute o comando refreshSessions. Para detalhes, consulte Atualizar um cursor com refreshSessions.

maxNumActiveUserIndexBuilds

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 3

Define o número máximo de construções de índice simultâneas permitidas no primary. Este é um limite global que se aplica a todas as collections.

Aumentar o valor de maxNumActiveUserIndexBuilds permite a criação de índices simultâneos adicionais ao custo de maior pressão sobre o cache do WiredTiger.

Os índices do sistema não estão limitados a maxNumActiveUserIndexBuilds, no entanto, uma compilação de índice do sistema conta em relação ao limite para compilações de índice do usuário.

Depois que o servidor atinge maxNumActiveUserIndexBuilds, ele bloqueia as compilações de índices adicionais do usuário até que o número de compilações de índices simultâneas caia abaixo do limite maxNumActiveUserIndexBuilds. Se uma construção de índice estiver bloqueada, o servidor registrará esta mensagem:

Too many index builds running simultaneously, waiting until the
number of active index builds is below the threshold.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O seguinte comando define um limite de 4 construções de índice simultâneas:

db.adminCommand( { setParameter: 1, maxNumActiveUserIndexBuilds: 4 } )

Veja também:

• maxIndexBuildMemoryUsageMegabytes

• Construções de índice em coleções preenchidas

notablescan

Disponível apenas para mongod.

Especifique se todas as consultas devem utilizar índices. Se 1, o MongoDB não executará consultas que exijam uma verificação de coleção e retornará um erro.

Considere o seguinte exemplo que define notablescan como 1 ou verdadeiro:

db.adminCommand( { setParameter: 1, notablescan: 1 } )

Definir notablescan como 1 pode ser útil para testar consultas de aplicativos, por exemplo, para identificar consultas que examinam uma coleção inteira e não podem usar um índice.

Para detectar queries não indexadas sem notablescan, considere ler as seções Analisar desempenho da query e Otimizar desempenho da query e usar o parâmetro logLevel, mongostat e a criação de perfil.

Não execute instâncias mongod de produção com notablescan porque impedir verificações de collections pode afetar potencialmente as queries em todos os bancos de dados, incluindo queries administrativas.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Observação

notablescan não permite queries ilimitadas que usam um índice clusterizado porque as queries exigem uma verificação completa da coleção. Para obter mais informações, consulte Verificações de coleção.

ttlMonitorEnabled

Disponível apenas para mongod.

Padrão: true

Para oferecer suporte a índices TTL, as instâncias mongod têm um thread em segundo plano que é responsável por excluir documentos de coleções com índices TTL.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Para desabilitar esse thread de trabalho para um mongod, defina ttlMonitorEnabled como false, como nas seguintes operações:

db.adminCommand( { setParameter: 1, ttlMonitorEnabled: false } )

Como alternativa, você pode desativar o thread no momento da inicialização iniciando a instância mongod com a seguinte opção:

mongod --setParameter ttlMonitorEnabled=false

Importante

Não execute instâncias mongod de produção com ttlMonitorEnabled desativado, exceto sob orientação do suporte do MongoDB. Impedir a remoção de documentos TTL pode impactar negativamente as operações internas do sistema MongoDB que dependem dos índices TTL.

tcpFastOpenServer

Disponível para mongod e mongos.

Padrão: true

Permite o suporte para aceitar conexões TCP Fast Open (TFO) de entrada para o mongod/mongos a partir de um cliente. O TFO requer suporte do cliente e da máquina host mongod/mongos e habilita o TFO:

Windows

Os seguintes sistemas operacionais Windows são compatíveis com TFO:

• Microsoft Windows Server 2016 e versões mais recentes.

• Microsoft Windows 10 Update 1607 e versões mais recentes.

macOS

O macOS 10.11 (El Capitan) e versões mais recentes suportam TFO.

Linux

Sistemas operacionais Linux que executam o Linux Kernel 3.7 ou posterior podem suportar TFO de entrada.

Configure o valor de /proc/sys/net/ipv4/tcp_fastopen para ativar conexões TFO de entrada:

• Defina como 2 para ativar somente conexões TFO de entrada.

• Defina como 3 para ativar conexões TFO de entrada e saída.

Este parâmetro não terá efeito se o sistema operacional do host não suportar ou não estiver configurado para suportar conexões TFO.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Dica

Veja também:

RFC7413.

tcpFastOpenClient

Disponível para mongod e mongos.

Padrão: true

Somente sistema operacional Linux

Habilita o suporte para conexões TCP Fast Open (TFO) de saída do mongod/mongos para um cliente. O TFO exige tanto o cliente quanto o suporte da máquina host do mongod/mongos e habilita o TFO.

Sistemas operacionais Linux que executam o Linux Kernel 4.11 ou posterior podem suportar TFO de saída.

Defina o valor de /proc/sys/net/ipv4/tcp_fastopen para habilitar conexões TFO de saída:

• 1 para habilitar somente conexões TFO de saída.

• 3 para habilitar conexões TFO de entrada e saída.

Este parâmetro não terá efeito se o sistema operacional do host não suportar ou não estiver configurado para suportar conexões TFO.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Dica

Veja também:

RFC7413.

tcpFastOpenQueueSize

Disponível para mongod e mongos.

Padrão: 1024

Como parte do estabelecimento de uma conexão TCP Fast Open (TFO), o cliente envia um cookie TFO válido para o mongod/mongos antes da conclusão do handshake tridirecional TCP padrão. O mongod/mongos mantém uma fila de todas essas conexões TFO pendentes.

O parâmetro tcpFastOpenQueueSize define o tamanho da fila de conexões TFO pendentes. Enquanto a fila estiver cheia, o mongod/mongos retorna ao handshake normal de três vias para solicitações de clientes de entrada e ignora a presença de cookies TFO. Quando o tamanho da fila estiver abaixo do limite, o mongod/mongos começará a aceitar novos cookies TFO.

• Aumentar o tamanho da fila padrão pode melhorar o efeito do TFO no desempenho da rede. No entanto, grandes tamanhos de fila também aumentam o risco de esgotamento de recursos do servidor devido ao excesso de solicitações de TFO de entrada.

• Diminuir o tamanho padrão da fila pode reduzir o risco de esgotamento dos recursos do servidor de recursos devido ao excesso de solicitações de TFO recebidas. No entanto, os tamanhos de fila pequenos também podem reduzir o efeito do TFO no desempenho da rede.

  O tamanho mínimo da fila é 0. Uma fila de 0 desabilita efetivamente o TFO.

Este parâmetro não tem efeito sobre os sistemas operacionais do host que não suportam ou não estão configurados para conexões TFO.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Dica

Veja também:

• Seção TCP Fast Open RFC7413 5: considerações de segurança

• Seção TCP Fast Open RFC7413 6: aplicabilidade do TFO

disableJavaScriptJIT

Disponível apenas para mongod.

O mecanismo JavaScript do MongoDB usa o SpiderMonkey, que implementa a compilação Just-in-Time (JIT) para melhorar o desempenho ao executar scripts.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Para habilitar o JIT, defina disableJavaScriptJIT como false, como no exemplo a seguir:

db.adminCommand( { setParameter: 1, disableJavaScriptJIT: false } )

Observação

$where reutilizará os contextos existentes do intérprete de JavaScript, portanto, as alterações em disableJavaScriptJIT podem não entrar em vigor imediatamente para essas operações.

Alternativamente, você pode habilitar o JIT no momento da inicialização iniciando a instância do mongod com a seguinte opção:

mongod --setParameter disableJavaScriptJIT=false

indexBuildMinAvailableDiskSpaceMB

Novidade na versão 7.1.

Disponível apenas para mongod.

Padrão: 500 MB

Define o espaço mínimo em disco disponível em megabytes necessários para compilações de índice.

Deve ser maior ou igual a 0 MB e menor ou igual a 8 TB. 0 desabilita o requisito mínimo de espaço em disco.

Uma nova compilação de índice não pode ser iniciada e uma compilação de índice atual é cancelada se o espaço disponível em disco estiver abaixo de indexBuildMinAvailableDiskSpaceMB.

Aviso

Se você aumentar o indexBuildMinAvailableDiskSpaceMB, certifique-se de que seu servidor tenha espaço em disco suficiente disponível. Além disso, se você definir indexBuildMinAvailableDiskSpaceMB muito alto, poderá impedir desnecessariamente as compilações de índices quando houver espaço em disco suficiente disponível e indexBuildMinAvailableDiskSpaceMB puder ser definido como mais baixo.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo seguinte define indexBuildMinAvailableDiskSpaceMB para 650 MB:

db.adminCommand( { setParameter: 1, indexBuildMinAvailableDiskSpaceMB: 650 } )

Você também pode definir indexBuildMinAvailableDiskSpaceMB na inicialização. Por exemplo:

mongod --setParameter indexBuildMinAvailableDiskSpaceMB=650

indexMaxNumGeneratedKeysPerDocument

Disponível para mongod e mongos.

Novidades na versão 5.3.

Padrão: 100000

Limita o número máximo de chaves geradas para um documento para evitar erros de memória. É possível aumentar o limite, mas se uma operação exigir mais chaves do que o parâmetro indexMaxNumGeneratedKeysPerDocument especifica, a operação falhará.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

maxIndexBuildMemoryUsageMegabytes

Disponível apenas para mongod.

Padrão: 200

Limita a quantidade de memória que as compilações simultâneas de índices em uma coleção podem consumir durante a duração das compilações. A quantidade especificada de memória é compartilhada entre todos os índices construídos utilizando um único comando createIndexes ou seu auxiliar de shell db.collection.createIndexes().

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

A memória consumida por uma construção de índice é separada da memória de cache do WiredTiger (consulte cacheSizeGB).

maxIndexBuildMemoryUsageMegabytes define um limite para a quantidade de memória que a construção de índice usa de uma só vez. Isso pode afetar o desempenho quando o processo de construção de índice gera e classifica chaves para o índice. O aumento do limite de memória melhora o desempenho da classificação durante a construção de índice.

As compilações de índice podem ser iniciadas por um comando de usuário, como createIndexes, ou por um processo administrativo, como uma sincronização inicial. Ambos estão sujeitos ao limite definido por maxIndexBuildMemoryUsageMegabytes.

Uma sincronização inicial preenche apenas uma coleção de cada vez e não tem risco de exceder o limite de memória. No entanto, é possível para um usuário iniciar compilações de índice em várias coleções de vários bancos de dados simultaneamente e potencialmente consumir uma quantidade de memória maior do que o limite definido por maxIndexBuildMemoryUsageMegabytes.

Dica

Para minimizar o impacto da criação de um índice em conjunto de réplicas e clusters fragmentados com fragmentos de conjuntos de réplicas, use um procedimento de compilação de índice contínuo, conforme descrito em Rolling Index Builds on Replica Sets.

Alterar maxIndexBuildMemoryUsageMegabytes não afeta uma construção de índice em andamento se ela já tiver iniciado uma verificação de coleção. No entanto, uma reconfiguração forçada do conjunto de réplicas reinicia a verificação da coleção e usa o maxIndexBuildMemoryUsageMegabytes mais atual fornecido.

• Para "4.2" e posteriores da versão de compatibilidade de recursos (fcv), o limite de memória de compilação de índice se aplica a todas as compilações de índice.

reportOpWriteConcernCountersInServerStatus

Disponível apenas para mongod.

Padrão: false

Um sinalizador booleano que determina se o método db.serverStatus() e serverStatus comando retornam informaçõesopWriteConcernCounters. [1]

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

[1]	Habilitar o reportOpWriteConcernCountersInServerStatus pode ter um impacto de desempenho negativo; especificamente, ao executar sem TLS.

watchdogPeriodSeconds

Disponível apenas para mongod.

Tipo: inteiro

Padrão: -1 (desativado)

Determina com que frequência o Storage Node Watchdog verifica o status dos sistemas de arquivos monitorados:

• O diretório --dbpath

• O diretório journal dentro do diretório --dbpath

• O diretório do arquivo --logpath

• O diretório do arquivo --auditPath

Os valores válidos de watchdogPeriodSeconds são:

• -1 (o padrão), para desabilitar/pausar o Storage Node Watchdog, ou

• Um número inteiro maior ou igual a 60.

Observação

• Se um sistema de arquivos em um diretório monitorado deixar de responder, pode ser necessário um máximo de quase duas vezes o valor de watchdogPeriodSeconds para encerrar o mongod.

• Se algum de seu diretório monitorado for um symlink para outros volumes, o Storage Node Watchdog não monitorará o destino do symlink. Por exemplo, se o mongod usa storage.directoryPerDB: true (ou --directoryperdb) e vincula um diretório de banco de dados a outro volume, o Storage Node Watchdog não segue o link simbólico para monitorar o destino.

Para habilitar o Storage Node Watchdog, watchdogPeriodSeconds deve ser definido durante a inicialização.

mongod --setParameter watchdogPeriodSeconds=60

Você só pode habilitar o Storage Node Watchdog na inicialização. No entanto, uma vez habilitado, você pode pausar o Storage Node Watchdog ou alterar o watchdogPeriodSeconds durante o tempo de execução.

Uma vez habilitado,

• Para pausar o Watchdog do nó de armazenamento durante o tempo de execução, defina watchdogPeriodSeconds como -1.

  db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )

• Para retomar ou alterar o período durante o tempo de execução, configure watchdogPeriodSeconds para um número maior ou igual a 60.

  db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )

Observação

É um erro definir watchdogPeriodSeconds em tempo de execução se o Storage Node Watchdog não tiver sido ativado no momento da inicialização.

tcmallocEnableBackgroundThread

Disponível para mongod e mongos.

Novidades na versão 8.0.

Tipo: booleano

Padrão: true

Se definido como true, tcmallocEnableBackgroundThread cria um thread em segundo plano que libera memória periodicamente de volta para o sistema operacional. O valor de tcmallocReleaseRate determina a taxa, em bytes por segundo, na qual o thread em segundo plano libera memória.

Observação

Se tcmallocEnableBackgroundThread for true e tcmallocReleaseRate for 0, o MongoDB ainda liberará memória.

Para melhorar o uso da memória, recomendamos usar o valor padrão de true. Para saber mais sobre melhorias no desempenho e no gerenciamento de memória, consulte Upgraded TCMalloc.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

A seguinte operação define tcmallocEnableBackgroundThread para false:

mongod --setParameter "tcmallocEnableBackgroundThread=false"

tcmallocReleaseRate

Disponível para mongod e mongos.

Alterado na versão 8.0.

Padrão: 0

Especifica a taxa de liberação do TCMalloc em bytes por segundo. "Taxa de liberação" refere-se à taxa mínima na qual o MongoDB libera memória não utilizada para o sistema. Para devolver a memória ao sistema mais rapidamente, aumente a taxa de liberação; para retornar a memória mais lentamente, diminua a taxa de liberação.

Observação

Se tcmallocEnableBackgroundThread for true e tcmallocReleaseRate for 0, o MongoDB ainda liberará memória.

A partir do MongoDB,8.0 o valor padrão de tcmallocReleaseRate foi reduzido para 0 devido a uma atualização do tcmalloc que prioriza o desempenho da CPU em relação à liberação de memória. Mesmo tcmallocReleaseRate 0tcmalloc que esteja definido tcmallocEnableBackgroundThread como, poderá liberar memória de volta para o sistema, especialmente se estiver próximo do limite de heap. Se o estiver habilitado, otcmalloc também poderá liberar memória de seus caches intermediários.

Em versões anteriores, o MongoDB usou uma versão mais antiga do tcmalloc que:

• Defina o tcmallocReleaseRate padrão como 1.

• Valores aceitos para tcmallocReleaseRate entre 0 e 10, inclusive.

Importante

Se você executar o MongoDB em uma plataforma que usa tcmalloc-gperf como Windows, PPC ou s390x, tcmallocReleaseRate terá o mesmo comportamento das versões anteriores do MongoDB .

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Para modificar a taxa de liberação durante o tempo de execução, você pode utilizar o comando. Por setParameter exemplo:

db.adminCommand( { setParameter: 1, tcmallocReleaseRate: 2097152 } )

Também é possível definir tcmallocReleaseRate no momento da inicialização; por exemplo:

mongod --setParameter "tcmallocReleaseRate=5.0"

fassertOnLockTimeoutForStepUpDown

Novidades na versão 5.3.

Disponível para mongod e mongos.

Padrão: 15 segundos

Permite que um servidor que receba uma solicitação de aumento ou redução seja encerrado se não conseguir atender (por exemplo, devido a discos defeituosos do servidor) dentro do tempo limite. Isso permite que um cluster eleja com êxito um novo nó primário e, assim, continue disponível.

fassertOnLockTimeoutForStepUpDown o padrão é 15 segundos. Para desativar o fasterting dos nós, defina fassertOnLockTimeoutForStepUpDown=0.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir desabilita o fasserting dos nós:

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

ingressAdmissionControllerTicketPoolSize

Disponível apenas para mongod.

Padrão: 1000000

Controla o número máximo de operações admitidas simultaneamente na fila de entrada. O valor padrão de 1000000 representa o equivalente numérico de ilimitados, que admite todas as operações de entrada até o máximo de conexões padrão que o MongoDB permite.

Aumentar esse valor enquanto há operações aguardando na fila desbloqueia quantas operações o novo tamanho do pool permitir. Diminuir esse valor não bloqueia nenhuma operação em execução no momento, mas as operações controláveis de entrada são bloqueadas até que haja tickets disponíveis.

mongod --setParameter ingressAdmissionControllerTicketPoolSize=100000

Aviso

Evite modificar ingressAdmissionControllerTicketPoolSize a menos que seja orientado pelos engenheiros do MongoDB. Essa configuração tem implicações importantes tanto no WiredTiger quanto no MongoDB.

Parâmetros de registro

logLevel

Disponível para mongod e mongos.

Especifique um número inteiro entre 0 e 5, significando a verbosidade do registro, em que 5 é o mais detalhado. [2]

O logLevel padrão é 0 (Informativo).

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define o logLevel para 2:

db.adminCommand( { setParameter: 1, logLevel: 2 } )

Dica

Veja também:

• logComponentVerbosity

• systemLog.verbosity

[2]	A partir da versão 4.2, o MongoDB inclui o nível de verbosidade de depuração (1-5) nas mensagens de registro. Por exemplo, se o nível de verbosidade for 2, o MongoDB registrará D2. Em versões anteriores, as mensagens de registro do MongoDB especificavam somente D para o nível de depuração.

logComponentVerbosity

Disponível para mongod e mongos.

Define os níveis de verbosidade de vários componentes para mensagens de registro. O nível de verbosidade determina a quantidade de mensagens informativas e de depuração que o MongoDB emite. [3]

O nível de verbosidade pode variar de 0 a 5:

• 0 é o nível de detalhamento de log padrão do MongoDB, para incluir mensagens informativas.

• 1 para 5 aumenta o nível de verbosidade para incluir mensagens de Depuração.

Para um componente, você também pode especificar -1 para herdar o nível de verbosidade dos pais.

Para especificar o nível de verbosidade, use um documento semelhante ao seguinte:

{
  verbosity: <int>,
  <component1>: { verbosity: <int> },
  <component2>: {
     verbosity: <int>,
     <component3>: { verbosity: <int> }
  },
  ...
}

Para os componentes, você pode especificar apenas o <component>: <int> no documento, a menos que esteja definindo o nível de detalhamento pai e o do(s) componente(s) filho(s) também:

{
  verbosity: <int>,
  <component1>: <int> ,
  <component2>: {
     verbosity: <int>,
     <component3>: <int>
  }
  ...
}

O campo verbosity de nível superior corresponde a systemLog.verbosity que define o nível padrão para todos os componentes. O valor padrão de systemLog.verbosity é 0.

Os componentes correspondem às seguintes configurações:

• accessControl

• command

• control

• ftdc

• geo

• index

• network

• query

• queryStats

• replication

• replication.election

• replication.heartbeats

• replication.initialSync

• replication.rollback

• recovery

• sharding

• storage

• storage.journal

• transaction

• write

A menos que explicitamente definido, o componente tem o nível de verbosidade de seu pai. Por exemplo, storage é o pai de storage.journal. Isto é, se você especificar um nível de verbosidade do storage, este nível também se aplicará a:

• storage.journal componentes a menos que você especifique o nível de verbosidade para storage.journal.

• storage.recovery componentes a menos que você especifique o nível de verbosidade para storage.recovery.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o seguinte define o default verbosity level como 1, o query como 2, o storage para 2e o storage.journal para 1.

db.adminCommand( {
   setParameter: 1,
   logComponentVerbosity: {
      verbosity: 1,
      query: { verbosity: 2 },
      storage: {
         verbosity: 2,
         journal: {
            verbosity: 1
         }
      }
   }
} )

Você também pode definir o parâmetro logComponentVerbosity no momento da inicialização, passando o documento de nível de verbosidade como uma string.

mongod --setParameter "logComponentVerbosity={command: 3}"

mongosh também fornece o db.setLogLevel() para definir o nível de log de um único componente. Para ver várias maneiras de definir o nível de verbosidade do log, consulte Configurar níveis de verbosidade do log.

[3]	A partir da versão 4.2, o MongoDB inclui o nível de verbosidade de depuração (1-5) nas mensagens de registro. Por exemplo, se o nível de verbosidade for 2, o MongoDB registrará D2. Em versões anteriores, as mensagens de registro do MongoDB especificavam somente D para o nível de depuração.

maxLogSizeKB

Disponível para mongod e mongos.

Tipo: número inteiro não negativo

Padrão: 10

Especifica o tamanho máximo, em kilobytes, para um campo de atributo individual em uma entrada de log; os atributos que excedem esse limite são truncados.

Os campos de atributo truncados imprimem o conteúdo do campo até o limite de maxLogSizeKB e imprimem o conteúdo do campo de impostos específicos ultrapassa esse limite, mantendo a formatação JSON válida. As entradas de log que contêm atributos truncados anexam um objeto truncated ao final da entrada de log.

Consulte truncamento de mensagem de log para obter mais informações.

Um valor 0 desativa totalmente o truncamento. Os valores negativos para este parâmetro não são válidos.

Aviso

Usar um valor grande ou desativar o truncamento com um valor 0 pode afetar negativamente o desempenho do sistema e afetar negativamente as operações do banco de dados.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define o tamanho máximo da linha de log para 20 kilobytes:

mongod --setParameter maxLogSizeKB=20

profileOperationResourceConsumptionMetrics

Disponível apenas para mongod.

Tipo: booleano

Padrão: false

Sinalizador que determina se as operações coletam métricas de consumo de recursos e as relatam nos logs de consulta lenta. Se você ativar a criação de perfil, essas métricas também serão incluídas.

Se configurado para true, executando o comando explain retornará operationMetrics quando o verbosidade for executionStats ou superior.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

quiet

Disponível para mongod e mongos.

Define o modo de registro silencioso. Se 1, mongod entrará em um modo de registro silencioso que não registrará os seguintes eventos/atividades:

• eventos de conexão;

• o comando drop, o comando dropIndexes, o comando validate; e

• atividades de sincronização de replicação.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Considere o seguinte exemplo que define o parâmetro quiet como 1:

db.adminCommand( { setParameter: 1, quiet: 1 } )

Dica

Veja também:

systemLog.quiet

redactClientLogData

Disponível para mongod e mongos.

Tipo: booleano

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

Configure o mongod ou mongos para redigir qualquer mensagem que acompanhe um determinado evento de log antes do log. Isso impede que o programa grave dados potencialmente confidenciais armazenados no banco de dados no registro de diagnóstico. Metadados como códigos de erro ou operação, números de linha e nomes de arquivos de origem ainda são visíveis nos registros.

Use redactClientLogData em conjunto com criptografia em descanso e TLS/SSL (criptografia de transporte) para auxiliar a conformidade com os requisitos normativos.

Para habilitar a redação de registro na inicialização, você pode:

• Inicie o mongod com a opção --redactClientLogData:

  mongod --redactClientLogData

• Configure a opção security.redactClientLogData no arquivo de configuração:

  security:
     redactClientLogData: true
     ...

Não é possível usar a opção --setParameter para definir redactClientLogData na inicialização.

Para habilitar a supressão de log em um mongod ou mongos em execução, utilize o seguinte comando:

db.adminCommand( { setParameter: 1, redactClientLogData : true } )

Dica

Veja também:

security.redactClientLogData

redactEncryptedFields

Novidades na versão 6.1.0.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Configura mongod e mongos para editar valores de campo de dados Binary criptografados de todas as mensagens de log.

• Se o parâmetro redactClientLogData ou a configuração security.redactClientLogData for definido como false e redactEncryptedFields for definido como true (o padrão), os campos criptografados serão suprimidos de todas as mensagens de log.

• Se o parâmetro redactClientLogData ou a configuração security.redactClientLogData estiver configurado para true, todos os campos serão suprimidos, independentemente da configuração redactEncryptedFields.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

traceExceptions

Disponível para mongod e mongos.

Configura mongod para registrar rastreamentos de pilha de código-fonte completo para cada exceção de banco de dados e soquete C++, para uso com depuração. Se true, mongod registrará rastreamentos completos de pilha.

Esse parâmetro só está disponível em tempo de execução. Para definir o parâmetro, use o comando setParameter.

Considere o exemplo a seguir que define traceExceptions como true:

db.adminCommand( { setParameter: 1, traceExceptions: true } )

Dica

Veja também:

systemLog.traceAllExceptions

suppressNoTLSPeerCertificateWarning

Disponível para mongod e mongos.

Tipo: booleano

Padrão: false

Por padrão, um mongod ou mongos com TLS/SSL habilitado e net.ssl.allowConnectionsWithoutCertificates : true permite que os clientes se conectem sem fornecer um certificado para validação enquanto registram um aviso. Defina suppressNoTLSPeerCertificateWarning como 1 ou true para suprimir esses avisos.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

A seguinte operação define suppressNoTLSPeerCertificateWarning para true:

db.adminCommand( { setParameter: 1, suppressNoTLSPeerCertificateWarning: true} )

enableDetailedConnectionHealthMetricLogLines

Novidades na versão 7.0.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Determina se devem ser habilitadas as mensagens de log específicas relacionadas às métricas de integridade da conexão do cluster. Se enableDetailedConnectionHealthMetricLogLines estiver definido como false, as seguintes mensagens de log serão desativadas, mas o MongoDB ainda coletará dados sobre as métricas de integridade da conexão do cluster:

Mensagem de registo	Descrição
Conexão TLS aceita do par	Indica que o servidor analisou com sucesso o certificado de par durante o handshake TLS com uma conexão de ingresso aceita.
Handshake TLS de entrada concluído	Indica que o aperto de mão TLS com uma conexão de ingresso está completo.
Olá, concluído	Indica que a conexão inicial da negociação foi concluída em uma conexão de cliente de entrada. O MongoDB exibe a mensagem de log somente com o primeiro comando hello.
Relatório de métricas de autenticação	Especifica a conclusão de uma etapa na conversa de autenticação.
Recebeu o primeiro comando na conexão de entrada desde o início da sessão ou a negociação de autenticação	Indica que uma conexão de entrada recebeu o primeiro comando que não faz parte da negociação.
Tempo de envio de resposta de rede lento	Indica que o tempo gasto, em milissegundos, para enviar a resposta de volta ao cliente por meio de uma conexão de entrada leva mais tempo do que a duração definida pelo parâmetro slowMS server.
Verificação concluída do lado do cliente da solicitação OCSP	Se o par não incluir uma resposta OCSP ao handshake TLS quando uma conexão TLS de saída for estabelecida, o servidor deverá enviar uma solicitação OCSP à autoridade de certificação. O MongoDB grava essa mensagem de log quando a autoridade de certificação recebe a resposta do OCSP.
Estabelecimento de conexão lenta	Indica que o tempo necessário para enviar uma resposta de volta ao cliente em uma conexão de entrada leva mais tempo do que o limite especificado com o parâmetro. O MongoDB também emite essa mensagem de registro quando o estabelecimento da conexão slowConnectionThresholdMillis expira.
A operação atingiu o tempo limite enquanto aguardava a aquisição da conexão	Indica que uma operação atingiu o tempo-limite enquanto aguardava a aquisição de uma conexão de saída.
Conexão adquirida para operação remota e escrita concluída no fio	Indica que o servidor levou um milissegundo ou mais para gravar uma solicitação de saída em uma conexão de saída, contando a partir do instante em que a conexão é estabelecida.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Parâmetros de diagnóstico

Para facilitar a análise do comportamento do servidor MongoDB pelos engenheiros do MongoDB, o MongoDB registra as estatísticas do servidor em arquivos de diagnóstico em intervalos periódicos.

Para mongod os arquivos de dados de diagnóstico são armazenados no diagnostic.data diretório sob o mongod --dbpath ou da storage.dbPath instância.

Para mongos os arquivos de dados de diagnóstico, por padrão, são armazenados em um diretório sob o mongos --logpath diretório ou systemLog.path da instância. O diretório de dados de diagnóstico é calculado truncando a(s) extensão(ões) de arquivo do caminho de registro e concatenando diagnostic.data ao nome restante.

Por exemplo, se mongos tiver --logpath /var/log/mongodb/mongos.log.201708015, o diretório de dados de diagnóstico será /var/log/mongodb/mongos.diagnostic.data/ diretório. Para especificar um diretório de dados de diagnóstico diferente para mongos, configure o parâmetro diagnosticDataCollectionDirectoryPath.

Os parâmetros a seguir suportam captura de dados de diagnóstico (FTDC):

diagnosticDataCollectionEnabled

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Determina se deseja habilitar a coleta e o registro de dados para fins de diagnóstico. O registro de diagnóstico está habilitado por padrão.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o seguinte desabilita a collection de diagnóstico:

mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionDirectoryPath

Disponível apenas para mongos.

Tipo: string

Aviso

Se a captura de dados de diagnóstico em tempo integral (FTDC) estiver desativada com diagnosticDataCollectionEnabled ou se systemLog.destination estiver definido como syslog, será necessário reiniciar mongos após definir diagnosticDataCollectionDirectoryPath.

Especifique o diretório para o diretório de diagnóstico paramongos. Se o diretório não existir, o mongos criará o diretório.

Se não for especificado, o diretório de dados de diagnóstico será calculado truncando as extensões de mongos arquivo --logpath ou da systemLog.path instância e concatenando diagnostic.data.

Por exemplo, se mongos tiver --logpath /var/log/mongodb/mongos.log.201708015, então o diretório de dados de diagnóstico será /var/log/mongodb/mongos.diagnostic.data/.

Se o mongos não puder criar o diretório especificado, a captura de dados de diagnóstico será desabilitada para esta instância. mongos talvez não seja possível criar o diretório especificado se um arquivo com o mesmo nome já existir no caminho ou se o processo não tiver permissões para criar o diretório.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

diagnosticDataCollectionDirectorySizeMB

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 200 (400 em clusters fragmentados)

Especifica o tamanho máximo, em megabytes, do diretório diagnostic.data. Se o tamanho do diretório exceder esse número, os arquivos de diagnóstico mais antigos do diretório serão excluídos automaticamente com base no carimbo de data/hora no nome do arquivo.

Alterado na versão 8.0: diagnosticDataCollectionDirectorySizeMB tem um valor padrão de 400 MB para instânciasmongos e mongod usadas em clusters fragmentados. mongod instâncias usadas no conjunto de réplicas ou como servidores autônomos têm um valor padrão de 200 MB.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o seguinte define o tamanho máximo do diretório para 250 megabytes:

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

O valor mínimo para diagnosticDataCollectionDirectorySizeMB é de 10 megabytes. diagnosticDataCollectionDirectorySizeMB deve ser maior que o tamanho máximo do arquivo de diagnóstico diagnosticDataCollectionFileSizeMB.

diagnosticDataCollectionFileSizeMB

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 10

Especifica o tamanho máximo, em megabytes, de cada arquivo de diagnóstico. Se o arquivo exceder o tamanho máximo permitido, o MongoDB criará um novo arquivo.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o seguinte define o tamanho máximo de cada arquivo de diagnóstico para 20 megabytes:

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

O valor mínimo para diagnosticDataCollectionFileSizeMB é de 1 megabytes.

diagnosticDataCollectionPeriodMillis

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 1000

Especifica o intervalo, em milissegundos, no qual coletar dados de diagnóstico.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, o seguinte define o intervalo para 5000 milissegundos ou 5 segundos:

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

O valor mínimo para diagnosticDataCollectionPeriodMillis é de 100 milissegundos.

Replicação e consistência

disableSplitHorizonIPCheck

Novidades na versão 5.0.0.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: false

Para configurar nós de cluster para DNS de horizonte dividido, use nomes de host em vez de endereços IP.

Começando no MongoDB v5,0, replSetInitiate e replSetReconfig rejeitam configurações que usam endereços IP em vez de nomes de host.

Utilize o disableSplitHorizonIPCheck para modificar nós que não podem ser atualizados para utilizar nomes de host. O parâmetro se aplica somente aos comandos de configuração.

O mongod e mongos não dependem de disableSplitHorizonIPCheck para a validação na inicialização. As instâncias legadas do mongod e mongos que usam endereços IP em vez de nomes de host podem ser iniciadas após a atualização.

As instâncias configuradas com endereços IP registram um aviso para usar nomes de host em vez de endereços IP.

Para permitir alterações de configuração utilizando endereços IP, defina disableSplitHorizonIPCheck=true utilizando a linha de comando:

/usr/local/bin/mongod  --setParameter disableSplitHorizonIPCheck=true -f /etc/mongod.conf

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

setParameter:
   disableSplitHorizonIPCheck: true

enableOverrideClusterChainingSetting

Novidades na versão 5.0.2.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: false

Se enableOverrideClusterChainingSetting for true, os membros secundários do conjunto de réplicas poderão replicar dados de outros membros secundários, mesmo que settings.chainingAllowed seja false.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para configurar o enableOverrideClusterChainingSetting de uma instância mongod como true:

mongod --setParameter enableOverrideClusterChainingSetting=true

logicalSessionRefreshMillis

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 300000 (5 minutos)

O intervalo (em milissegundos) no qual o cache atualiza seus registros de sessão lógica no armazenamento de sessão principal.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para definir o logicalSessionRefreshMillis de uma instância mongod como 10 minutos:

mongod --setParameter logicalSessionRefreshMillis=600000

localLogicalSessionTimeoutMinutes

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 30

Aviso

Apenas para fins de teste

Este parâmetro destina-se apenas a fins de teste e não para uso de produção.

O tempo em minutos em que uma sessão permanece ativa após seu uso mais recente. As sessões que não receberam uma nova operação de leitura/gravação do cliente ou foram atualizadas com refreshSessions dentro desse limite são apagadas do cache. O estado associado a uma sessão expirada pode ser limpo pelo servidor a qualquer momento.

Este parâmetro se aplica somente à instância na qual está definido. Para definir esse parâmetro em conjuntos de réplicas e clusters fragmentados, você deve especificar o mesmo valor em cada membro; caso contrário, as sessões não funcionarão corretamente.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para configurar o localLogicalSessionTimeoutMinutes de uma instância mongod de teste como 20 minutos:

mongod --setParameter localLogicalSessionTimeoutMinutes=20

maxAcceptableLogicalClockDriftSecs

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 31536000 (1 ano)

O valor máximo pelo qual o tempo atual do cluster pode ser avançado; especificamente, maxAcceptableLogicalClockDriftSecs é a diferença máxima entre o novo valor do tempo do cluster e o tempo atual do cluster. O tempo do cluster é um tempo lógico usado para ordenar operações.

Não é possível avançar a hora do cluster para um novo valor se a nova hora do cluster for diferente da hora do cluster atual em mais de maxAcceptableLogicalClockDriftSecs.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para definir o maxAcceptableLogicalClockDriftSecs de uma instância mongod como 15 minutos:

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxSessions

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 1000000

O número máximo de sessões que podem ser armazenadas em cache.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para configurar o maxSessions de uma instância mongod como 1000:

mongod --setParameter maxSessions=1000

oplogBatchDelayMillis

Novidades na versão 6.0.

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 0

O número de milissegundos para atrasar a aplicação de lotes de operações de oplog em nós secundários. Por padrão, oplogBatchDelayMillis é 0, o que significa que os lotes de oplog são aplicados sem atraso. Quando não há atraso, o MongoDB pode aplicar lotes de oplog pequenos e frequentes a secundários.

O aumento do oplogBatchDelayMillis faz com que o MongoDB aplique lotes de oplog com menos frequência em secundários, com cada lote contendo maiores quantidades de dados. Isso reduz a IOPS em secundários, mas adiciona latência para gravações com write concern "majority".

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, execute o seguinte comando para configurar o oplogBatchDelayMillis para uma instância mongod para 20 milissegundos:

mongod --setParameter oplogBatchDelayMillis=20

periodicNoopIntervalSecs

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 10

A duração em segundos entre noop escreve em cada nó individual.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Observação

Para modificar este valor para um cluster do MongoDB Atlas, você deve entrar em contato com o suporte do Atlas.

O exemplo a seguir define o periodicNoopIntervalSecs como 1 segundo na inicialização:

mongod --setParameter periodicNoopIntervalSecs=1

storeFindAndModifyImagesInSideCollection

Novidades na versão 5.0.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Determina se os documentos temporários exigidos para comandos repetíveis findAndModify são armazenados na coleção side (config.image_collection).

Se storeFindAndModifyImagesInSideCollection for:

• true, os documentos temporários são armazenados na coleção lateral.

• false, os documentos temporários são armazenados no oplog do conjunto de réplicas.

Mantenha storeFindAndModifyImagesInSideCollection configurado para true se você:

• Tenha uma grande carga de trabalho repetível findAndModify.

• Exigir mais espaço temporário no documento para comandos de repetíveis do que o findAndModify disponível no oplog do conjunto de réplicas.

Observação

Os secundários podem experimentar aumento no uso da CPU quando storeFindAndModifyImagesInSideCollection for true.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, para configurar storeFindAndModifyImagesInSideCollection como false durante a inicialização:

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, storeFindAndModifyImagesInSideCollection: false } )

TransactionRecordMinimumLifetimeMinutes

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 30

O tempo mínimo de permanência de um registro de transação na coleção transactions antes que o registro se torne elegível para limpeza.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, para definir o TransactionRecordMinimumLifetimeMinutes de uma instância mongod como 20 minutos:

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Dica

Veja também:

localLogicalSessionTimeoutMinutes

enableFlowControl

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Habilita ou desabilita o mecanismo que controla a taxa na qual o primário aplica suas gravações com o objetivo de manter o atraso demajority committed dos membros secundários sob um valor máximo configurável.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Observação

Para que o controle de fluxo seja ativado, o conjunto de réplicas/cluster fragmentado deve ter: featureCompatibilityVersion (fCV) de 4.2 e preocupação de leitura majority enabled. Ou seja, o controle de fluxo ativado não terá efeito se fCV não for 4.2 ou se a maioria das preocupações de leitura estiver desativada.

flowControlTargetLagSeconds

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 10

O alvo máximo majority committed defasagem ao executar com controle de fluxo. Quando o controle de fluxo está habilitado, o mecanismo tenta manter o atrasomajority committed sob os segundos especificados. O parâmetro não terá efeito se o controle de fluxo estiver desabilitado.

O valor especificado deve ser maior que 0.

Em geral, as configurações padrão devem ser suficientes; no entanto, se modificar a partir do valor padrão, diminuindo, em vez de aumentar, o valor pode revelar-se mais útil.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

flowControlWarnThresholdSeconds

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 10

A quantidade de tempo que deve aguardar para registrar um aviso depois que o mecanismo de controle de fluxo detecta o ponto de confirmação da maioria não foi movida.

O valor especificado deve ser maior ou igual a 0, com 0 para desabilitar os avisos.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

initialSyncTransientErrorRetryPeriodSeconds

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 86400

A quantidade de tempo em segundos que um secundário executando a sincronização inicial tenta retomar o processo se for interrompido por um erro de rede transitório. O valor padrão é equivalente a 24 horas.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

initialSyncSourceReadPreference

Disponível apenas para mongod.

Tipo: string

A fonte preferencial para executar a initial sync. Especifique um dos seguintes modos de read preference:

• primary

• primaryPreferred (Padrão para membros do conjunto de réplicas votantes)

• secondary

• secondaryPreferred

• nearest (Padrão para membros do conjunto de réplicas recém-adicionados ou sem direito a voto)

Se o conjunto de réplicas tiver desabilitado chaining, o modo de preferência de leitura initialSyncSourceReadPreference padrão será primary.

Você não pode especificar um conjunto de tags ou maxStalenessSeconds para initialSyncSourceReadPreference.

Se o mongod não conseguir localizar uma fonte de sincronização com base na preferência de leitura especificada, ele registrará um erro e reiniciará o processo de sincronização inicial. O mongod sai com um erro se não conseguir concluir o processo de sincronização inicial após 10 tentativas. Para obter mais informações sobre a seleção da fonte de sincronização, consulte Seleção inicial da fonte de sincronização.

initialSyncSourceReadPreference tem precedência sobre a configuração settings.chainingAllowed do conjunto de réplicas ao selecionar uma fonte de sincronização inicial. Depois que um conjunto de réplicas conclui com êxito a sincronização inicial, ele adia o valor de chainingAllowed ao selecionar uma fonte de sincronização de replicação.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

initialSyncMethod

Novidades na versão 5.2.

Disponível apenas para mongod.

Tipo: string

Padrão: logical

Disponível apenas no MongoDB Enterprise.

Método usado para initial sync.

Configure para logical para utilizar a sincronização inicial lógica. Configure para fileCopyBased para utilizar a sincronização inicial baseada em cópia de arquivo.

Este parâmetro afeta somente o método de sincronização do membro no qual ele é especificado. A definição desse parâmetro em um único membro do conjunto de réplicas não afeta o método de sincronização de nenhum outro membro do conjunto de réplicas.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

maxNumSyncSourceChangesPerHour

Disponível para mongod e mongos.

Novidades na versão 5.0.

Tipo: inteiro

Padrão: 3

Fontes de sincronização são avaliadas toda vez que uma fonte de sincronização é atualizada e toda vez que um nó obtém um lote de entradas de oplog. Se houver mais de maxNumSyncSourceChangesPerHour alterações de origem em uma hora, o nó interromperá temporariamente a reavaliação dessa origem de sincronização. Se este parâmetro for configurado com um valor alto, o nó poderá fazer alterações de origem desnecessárias.

Esse parâmetro não impedirá que um nó comece a sincronizar de outro nó se ele não tiver uma origem de sincronização. O nó reavaliará se uma origem de sincronização se tornar inválida. Da mesma forma, se as alterações primárias e o encadeamento estiverem desabilitados, o nó será atualizado para sincronização a partir do novo primário.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

oplogFetcherUsesExhaust

Disponível apenas para mongod.

Tipo: booleano

Padrão: true

Habilita ou desabilita a replicação de streaming. Configure o valor para true para habilitar a replicação de streaming.

Defina o valor como false para desativar a replicação de streaming. Se estiver desativado, os secundários obtêm lotes de entradas do oplog emitindo uma solicitação para sua sincronização a partir da origem e aguardando uma resposta. Isso requer uma viagem de ida e volta da rede para cada lote de entradas de oplog.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

oplogInitialFindMaxSeconds

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 60

Tempo máximo, em segundos, para que um membro de um conjunto de réplicas aguarde a conclusão do comando find durante a sincronização de dados.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

replWriterThreadCount

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 16

Número máximo de threads a utilizar para aplicar operações replicadas em paralelo. Os valores podem variar de 1 a 256 inclusive. No entanto, o número máximo de threads usados é limitado a duas vezes o número de núcleos disponíveis.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Dica

Veja também:

replWriterMinThreadCount

replWriterMinThreadCount

Novidades na versão 5.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 0

Número mínimo de threads utilizadas para aplicar operações replicadas em paralelo. Os valores podem variar de 0 a 256. Você só pode definir replWriterMinThreadCount na inicialização e não pode alterar essa configuração com o comando setParameter.

O aplicativo paralelo de operações de replicação usa até replWriterThreadCount threads. Se replWriterMinThreadCount estiver configurado com um valor menor que replWriterThreadCount, o pool de threads atingirá o timeout de threads ociosos até que a contagem total de threads no pool de threads seja igual a replWriterMinThreadCount.

replWriterMinThreadCount deve ser configurado com um valor menor ou igual a replWriterThreadCount.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

rollbackTimeLimitSecs

Disponível apenas para mongod.

Tipo: número inteiro de 64 bits

Padrão: 86400 (1 dias)

Idade máxima dos dados que podem ser revertidos. Os valores negativos para este parâmetro não são válidos.

Se o tempo entre o fim do oplog da instância a ser revertida e a primeira operação após o ponto comum (o último ponto em que o nó de origem e o nó a ser revertido tinham os mesmos dados) exceder esse valor, a reversão falhará.

Para efetivamente ter um período de rollback ilimitado, defina o valor como 2147483647, que é o valor máximo permitido e equivalente a aproximadamente 68 anos.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

waitForSecondaryBeforeNoopWriteMS

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 10

O período de tempo (em milissegundos) que um secundário deve esperar se afterClusterTime for maior que o último tempo aplicado do oplog. Após a passagem do waitForSecondaryBeforeNoopWriteMS, se o afterClusterTime ainda for maior que o último tempo aplicado, o secundário faz uma gravação no-op para avançar o último tempo aplicado.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define waitForSecondaryBeforeNoopWriteMS para 20 milissegundos:

mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, waitForSecondaryBeforeNoopWriteMS: 20 } )

createRollbackDataFiles

Disponível apenas para mongod.

Tipo: booleano

Padrão: true

Sinalizador que determina se o MongoDB cria arquivos de rollback que contêm documentos afetados durante um rollback.

Por padrão, o createRollbackDataFiles é true e o MongoDB cria os arquivos de rollback.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define createRollbackDataFiles como falso para que os arquivos de rollback não sejam criados:

mongod --setParameter createRollbackDataFiles=false

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, createRollbackDataFiles: false } )

Para obter mais informações, consulte Coletar dados de rollback.

replBatchLimitBytes

Disponível para mongod e mongos.

Default: 104857600 (100MB)

Define o tamanho máximo do lote do aplicativo oplog em bytes.

Os valores podem variar de 16777216 (16MB) a 104857600 (100MB), inclusive.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define replBatchLimitBytes como 64 MB para limitar o tamanho do lote do aplicativo oplog:

mongod --setParameter replBatchLimitBytes=67108864

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, replBatchLimitBytes: 64 * 1024 * 1024 } )

mirrorReads

Disponível apenas para mongod.

Tipo: documento

Padrão: { samplingRate: 0.01, maxTimeMS: 1000 }

Especifica as configurações para leituras espelhadas para a instância do mongod. As configurações só entram em vigor quando o membro é primário.

O parâmetro mirrorReads utiliza um documento JSON com os seguintes campos:

Campo	Descrição
samplingRate	A taxa de amostragem usada para espelhar um subconjunto de operações que suportam o espelhamento para um subconjunto de secundários selecionáveis (especificamente, priority greater than 0). Ou seja, os espelhos primários lêem cada secundário elegível na taxa de amostragem especificada. Os valores válidos são: 0.0 Desativa o espelhamento. 1.0 O primary espelha todas as operações que suportam espelhamento para cada secundário elegível. Número entre 0.0 e 1.0 (exclusivo) O primary coleta amostras aleatórias de cada secundário elegível na taxa especificada para o envio de leituras espelhadas. Por exemplo, dado um conjunto de réplicas com um primário e dois secundários elegíveis e uma taxa de amostragem de 0.10, os espelhos primários lêem para cada secundário elegível à taxa de amostragem de 10 por cento, de modo que uma leitura pode ser espelhada para um secundário e não para o outro ou para ambos ou para nenhum dos dois. Ou seja, se o primário recebe 100 operações que podem ser espelhadas, a taxa de amostragem de 0.10 pode resultar em leituras 8 sendo espelhadas para um secundário e 13 leituras para o outro ou 10 para cada um, etc. O valor padrão é 0.01.
maxTimeMS	O tempo máximo em milissegundos para as leituras espelhadas. O valor padrão é 1000. O maxTimeMS para as leituras espelhadas é separado do maxTimeMS da leitura original sendo espelhada.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Se você especificar a partir do arquivo de configuração ou na linha de comando, coloque o documento mirrorReads entre aspas.

Por exemplo, o seguinte define a taxa de amostragem de leitura do espelho como 0.10 na linha de comando:

mongod --setParameter mirrorReads='{ samplingRate: 0.10 }'

Ou para especificar em um arquivo de configuração:

setParameter:
   mirrorReads: '{samplingRate: 0.10}'

Ou, se estiver usando o comando setParameter em uma sessão mongosh conectada a um mongod em execução, não coloque o documento entre aspas:

db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )

allowMultipleArbiters

Novidades na versão 5.3.

Disponível apenas para mongod.

Tipo: booleano

Padrão: false

Especifica se o conjunto de réplicas permite o uso de vários arbiters.

O uso de vários arbiters não é recomendado:

• Vários árbitros impedem o uso confiável da preocupação com gravação da maioria. O MongoDB conta árbitros no cálculo da maioria de membros, mas os árbitros não armazenam dados. Com a inclusão de vários árbitros, é possível que uma operação de gravação majoritária retorne com êxito antes que a gravação seja replicada para a maioria dos nós com dados portadores.

• Vários árbitros permitem que conjuntos de réplicas aceitem gravações mesmo quando o conjunto de réplicas não tem segundários suficientes para a replicação de dados.

Para obter mais informações, consulte Preocupações com vários arbiters.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongod --setParameter allowMultipleArbiters=true

Parâmetros de fragmentação

analyzeShardKeyCharacteristicsDefaultSampleSize

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 10000000

Se sampleRate e sampleSize não estiverem definidos quando você executar analyzeShardKey, especifica o número de documentos a serem amostrados ao calcular as métricas de características-chave do fragmento. Deve ser maior que 0.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define analyzeShardKeyCharacteristicsDefaultSampleSize como 10000 na inicialização:

mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, analyzeShardKeyCharacteristicsDefaultSampleSize: 10000 } )

analyzeShardKeyNumMostCommonValues

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 5

Especifica o número de valores da chave de shard mais comuns a serem retornados. Se a collection contiver menos chaves de shard exclusivas do que esse valor, analyzeShardKeyNumMostCommonValues retornará esse número de valores mais comuns. Deve ser maior que 0 e menor ou igual a 1000.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define analyzeShardKeyNumMostCommonValues como 3 na inicialização:

mongod --setParameter analyzeShardKeyNumMostCommonValues=3

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, analyzeShardKeyNumMostCommonValues: 3 } )

analyzeShardKeyNumRanges

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 100

Especifica o número de intervalos em que o espaço de chave de fragmento deve ser particionado ao calcular o hotness dos intervalos de chave de fragmento. Deve ser maior que 0 e menor ou igual a 10000.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define analyzeShardKeyNumRanges como 50 na inicialização:

mongod --setParameter analyzeShardKeyNumRanges=50

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, analyzeShardKeyNumRanges: 50 } )

analyzeShardKeyMonotonicityCorrelationCoefficientThreshold

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: double

Padrão: 0.7

Especifica o limite de coeficiente de correlação do RecordId utilizado para determinar se uma chave de shard está mudando monotonicamente na ordem de inserção. Deve ser maior que 0 e menor ou igual a 1.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define analyzeShardKeyMonotonicityCorrelationCoefficientThreshold como 1 na inicialização:

mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, analyzeShardKeyMonotonicityCorrelationCoefficientThreshold: 1 } )

autoMergerIntervalSecs

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 3600

Quando AutoMerger está habilitado, especifica o tempo entre as rodadas de mesclagem automática, em segundos. O valor padrão é 3600 segundos ou uma hora.

autoMergerIntervalSecs só pode ser definido em servidores de configuração.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define autoMergerIntervalSecs a 7200 segundos, ou duas horas, na inicialização:

mongod --setParameter autoMergerIntervalSecs=7200

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, autoMergerIntervalSecs: 7200 } )

autoMergerThrottlingMS

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 15000

Quando o AutoMerger está habilitado, especifica o tempo mínimo entre as fusões iniciadas pelo AutoMerger na mesma coleção, em milissegundos.

autoMergerThrottlingMS só pode ser definido em servidores de configuração.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define autoMergerThrottlingMS a 60000 milissegundos, ou um minuto, na inicialização:

mongod --setParameter autoMergerThrottlingMS=60000

Durante o tempo de execução, você pode configurar ou modificar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, autoMergerThrottlingMS: 60000 } )

balancerMigrationsThrottlingMs

Novidade na versão 7.0: (Disponível também a partir de 6.3.1, 6.0.6, 5.0.18)

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 1000

Especifica a quantidade mínima de tempo entre duas rodadas de equilíbrio consecutivas. Isso permite que você reduza a taxa de balanceamento. Este parâmetro só entra em vigor nos nós do servidor de configuração.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define de balancerMigrationsThrottlingMs a 2000 milissegundos na inicialização:

mongod --setParameter balancerMigrationsThrottlingMs=2000

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, balancerMigrationsThrottlingMs: 2000 } )

chunkDefragmentationThrottlingMS

Novidades na versão 5.3.

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 0

Especifica o período de tempo mínimo (em milissegundos) entre comandos consecutivos de divisão e mesclagem executados pelo balanceador quando as partes em uma coleção fragmentada são desfragmentadas. chunkDefragmentationThrottlingMS limita a taxa de comandos de divisão e mesclagem.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define chunkDefragmentationThrottlingMS como 10 milissegundos:

mongod --setParameter chunkDefragmentationThrottlingMS=10

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, chunkDefragmentationThrottlingMS: 10 } )

chunkMigrationConcurrency

Disponível começando no MongoDB 7.0, 6.3, 6.0.6 (e 5.0.15).

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 1

Especifica um número inteiro que define o número de threads no shard de origem e o shard de destino para migração de chunk. As migrações de chunk usam o número de threads que você definiu no shard de destino para o shard de origem e de destino.

O aumento da simultaneidade melhora o desempenho da migração de blocos, mas também aumenta a carga de trabalho e o uso de IOPS de disco no estilhaço de origem e no estilhaço de recebimento.

O valor máximo é 500.

Normalmente, você deve usar metade do número total de núcleos de CPU como threads. Por exemplo, se o total for 16 núcleos, defina chunkMigrationConcurrency para 8 threads (ou menos).

Se o chunkMigrationConcurrency for maior que 1, a configuração do _secondaryThrottle será ignorada. A configuração _secondaryThrottle determina quando a migração de bloco prossegue com o próximo documento no bloco. Para obter detalhes, consulte Intervalo de migração e replicação.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define chunkMigrationConcurrency como 5:

mongod --setParameter chunkMigrationConcurrency=5

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, chunkMigrationConcurrency: 5 } )

Para configurar o balanceamento de collection, consulte configureCollectionBalancing.

Para saber mais sobre como desfragmentar coleções fragmentadas, consulte Desfragmentar coleções fragmentadas.

disableResumableRangeDeleter

Disponível apenas para mongod.

Tipo: booleano

Padrão: false

Se definido no primário de um fragmento, especifica se a exclusão do intervalo está pausada no fragmento. Se definido como true, a limpeza de intervalos que contêm documentos órfãos é pausada. O fragmento pode continuar a doar pedaços para outros fragmentos, mas os documentos doados não serão removidos desse fragmento até que você defina esse parâmetro como false. Esse fragmento pode continuar a receber blocos de outros fragmentos, desde que não tenha uma tarefa de exclusão de intervalo pendente na coleção config.rangeDeletions que se sobreponha ao intervalo do bloco de entrada.

Quando disableResumableRangeDeleter for true, as migrações das partes falharão se houver documentos órfãos no fragmento primário do destinatário na mesma faixa das partes recebidas.

O parâmetro não tem efeito no mongod se não for o principal do fragmento.

Importante

Se você definir o parâmetro disableResumableRangeDeleter como true, certifique-se de aplicá-lo de forma consistente a todos os membros no conjunto de réplicas do fragmento. No caso de um failover, o valor dessa configuração no novo primário dita o comportamento do excludente de intervalo.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongod --setParameter disableResumableRangeDeleter=false

enableShardedIndexConsistencyCheck

Disponível apenas para mongod.

Tipo: booleano

Padrão: true

Se definido no servidor de configuração primário, habilita ou desabilita a verificação de consistência do índice para coleções fragmentadas. O parâmetro não terá efeito sobre o mongod se ele não for o principal do servidor de configuração.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

O exemplo a seguir define enableShardedIndexConsistencyCheck como false para um servidor de configuração primário:

mongod --setParameter enableShardedIndexConsistencyCheck=false

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, enableShardedIndexConsistencyCheck: false } )

Dica

Veja também:

• shardedIndexConsistencyCheckIntervalMS parameter

• shardedIndexConsistency métricas retornadas pelo comando serverStatus.

opportunisticSecondaryTargeting

Novidades na versão 6.1.0.

Disponível apenas para mongos.

Tipo: booleano

Padrão: false

Determina se o mongos realiza leituras oportunistas contra conjuntos de réplicas.

Quando esse parâmetro é definido como true, mongos direciona as leituras secundárias para secundárias com conexões ativas. Ele envia a solicitação para o primeiro secundário que aceita a conexão. Quando esse parâmetro é definido como false, mongos retém leituras secundárias até que possa estabelecer uma conexão com uma secundária específica (exceto no caso de leituras protegidas).

Observação

Sob certas cargas de trabalho, leituras oportunistas podem desencadear a abertura de conexões desnecessárias de mongos para mongod e reduzir o desempenho geral. Este parâmetro não deve ser habilitado a menos que seu aplicativo tenha uma necessidade específica para a feição.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, para configurar o opportunisticSecondaryTargeting durante a inicialização:

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 600000

Se definido no primary do servidor de configuração, o intervalo, em milissegundos, no qual o primary do servidor de configuração verifica a consistência do índice das collections fragmentadas. O parâmetro não tem efeito sobre o mongod se ele não for o primary do servidor de configuração.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

Por exemplo, o seguinte define o intervalo em 300000 milissegundos (5 minutos) na inicialização:

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Dica

Veja também:

• enableShardedIndexConsistencyCheck parameter

• shardedIndexConsistency métricas retornadas pelo comando serverStatus.

enableFinerGrainedCatalogCacheRefresh

Observação

Depreciado em 8.0

A partir do MongoDB 8.0, o parâmetro está obsoleto e não causa alterações ou erros.

Disponível para mongod e mongos.

Tipo: booleano

Padrão: true

Este parâmetro permite que o cache do catálogo seja atualizado somente se o shard precisar ser atualizado. Se estiver desabilitado, qualquer chunk obsoleto fará com que toda a distribuição de chunk de uma collection seja considerada obsoleta e forçará todos os roteadores que entrarem em contato com o shard a atualizar o cache do catálogo de shards.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

mongod --setParameter enableFinerGrainedCatalogCacheRefresh=true
mongos --setParameter enableFinerGrainedCatalogCacheRefresh=true

Dica

Veja também:

• Fragmentação

• shardingStatistics.catalogCache

maxTimeMSForHedgedReads

Importante

A partir do MongoDB 8.0, as leituras distribuídas estão obsoletas. As queries que especificam a read preference nearest não usam mais leituras protegidas por padrão. Se você especificar explicitamente uma leitura com hedge, o MongoDB executará uma leitura com hedge e registrará um aviso.

Disponível apenas para mongos.

Tipo: inteiro

Padrão: 150

Especifica o limite de tempo máximo (em milissegundos) para a leitura distribuída. Ou seja, a leitura adicional enviada para proteger a operação de leitura usa o valor maxTimeMS de maxTimeMSForHedgedReads, enquanto a operação de leitura que está sendo protegida usa o valor maxTimeMS especificado para a operação.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, para definir o limite para 200 milissegundos, você pode emitir o seguinte durante a inicialização:

mongos --setParameter maxTimeMSForHedgedReads=200

Ou se estiver usando o comando setParameter em uma sessão mongosh conectada a um mongos:

db.adminCommand( { setParameter: 1, maxTimeMSForHedgedReads: 200 } )

Dica

Veja também:

• readHedgingMode

• Leituras cobertas

maxCatchUpPercentageBeforeBlockingWrites

Novidades na versão 5.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 10

Para operações moveChunk e moveRange, especifica a porcentagem máxima de dados não transferidos permitida pelo protocolo de migração (expressa em porcentagem do tamanho total do bloco) para a transição da fase catchup para a fase commit.

A definição de uma porcentagem de recuperação mais alta pode diminuir o tempo necessário para a conclusão da migração, ao custo de maior latência durante as operações upsert e delete simultâneas.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

A partir do MongoDB 7.1 (e 7.0.1), Você pode definir o parâmetro durante o tempo de execução.

Por exemplo, para definir a porcentagem máxima para 20, você pode emitir o seguinte durante a inicialização:

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

A partir do MongoDB 7.1 (e 7.0.1), você pode definir o parâmetro durante o tempo de execução com o comando setParameter :

db.adminCommand( { setParameter: 1, maxCatchUpPercentageBeforeBlockingWrites: 20} )

Dica

Veja também:

Protocolo de migração live

metadataRefreshInTransactionMaxWaitBehindCritSecMS

Novidade na versão 5.2: (Disponível também a partir de 5.1.0, 5.0.4)

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 500

Limita o tempo que um fragmento espera por uma seção crítica em uma transação.

Quando uma query acessa um fragmento, uma migração de partes ou uma operação DDL pode já conter a seção crítica da coleção. Se a query encontrar a seção crítica, o fragmento espera até que a seção crítica seja liberada. Quando o fragmento retorna o controle para mongos, mongos tenta novamente a query. No entanto, se uma transação com vários shards interagir com uma operação que usa a seção crítica em vários shards, a interação poderá resultar em um deadlock distribuído.

metadataRefreshInTransactionMaxWaitBehindCritSecMS limita o tempo máximo que um fragmento espera dentro de uma transação para que a seção crítica seja liberada.

Para reduzir o tempo máximo de espera para a seção crítica dentro de uma transação, reduza o valor de metadataRefreshInTransactionMaxWaitBehindCritSecMS.

Aviso

Se metadataRefreshInTransactionMaxWaitBehindCritSecMS for muito baixo, mongos poderá usar todas as suas tentativas de repetição e retornar um erro.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Por exemplo, para definir metadataRefreshInTransactionMaxWaitBehindCritSecMS para 400 milissegundos:

db.adminCommand( { setParameter: 1, metadataRefreshInTransactionMaxWaitBehindCritSecMS: 400 } )

queryAnalysisSamplerConfigurationRefreshSecs

Novidades na versão 7.0.

Alterado na versão 7.0.1.

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 10

Intervalo que um amostrador (mongos ou mongod) atualiza suas taxas de amostragem do analisador de query.

A taxa de amostragem configurada pelo comando configureQueryAnalyzer é dividida entre mongos instâncias no agrupamento fragmentado ou mongod instâncias no conjunto de réplicas baseado no tráfego que passa por elas. Para tornar a atribuição da taxa de amostragem para mongos ou mongod mais responsiva ao tráfego que passa por ela, diminua esse valor.

Recomendamos usar o valor padrão.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

A partir do MongoDB 7.0.1, você pode configurar o queryAnalysisSamplerConfigurationRefreshSecs durante o tempo de execução.

Este exemplo define queryAnalysisSamplerConfigurationRefreshSecs para 60 segundos na inicialização em uma instância do mongod:

mongod --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

Este exemplo define queryAnalysisSamplerConfigurationRefreshSecs para 60 segundos na inicialização em uma instância do mongos:

mongos --setParameter queryAnalysisSamplerConfigurationRefreshSecs=60

Para definir o valor em 30 segundos, execute o seguinte:

db.adminCommand( { setParameter: 1, queryAnalysisSamplerConfigurationRefreshSecs: 30 } )

queryAnalysisWriterIntervalSecs

Novidades na versão 7.0.

Alterado na versão 7.0.1.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 90

Intervalo em que as queries de amostra são gravadas no disco, em segundos.

Este parâmetro está disponível apenas na inicialização. Para definir o parâmetro, use a configuração setParameter.

A partir do MongoDB 7.0.1, você pode configurar o queryAnalysisWriterIntervalSecs durante o tempo de execução.

Este exemplo define queryAnalysisWriterIntervalSecs para 60 segundos na inicialização em uma instância do mongod:

mongod --setParameter queryAnalysisWriterIntervalSecs=60
To set the value to 60 seconds, run the following:

db.adminCommand( { setParameter: 1, queryAnalysisWriterIntervalSecs: 60 } )

queryAnalysisWriterMaxMemoryUsageBytes

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 100 * 1024 * 1024

Quantidade máxima de memória em bytes que o escritor de amostragem de query pode usar. Quando o limite for atingido, todas as novas queries e diffs serão descartados da amostragem até que o buffer seja liberado. Deve ser maior que 0.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define queryAnalysisWriterMaxMemoryUsageBytes como 10000000 na inicialização de uma instância mongod :

mongod --setParameter queryAnalysisWriterMaxMemoryUsageBytes=10000000

queryAnalysisWriterMaxBatchSize

Novidades na versão 7.0.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 100000

Número máximo de amostras de queries para gravar em disco de uma só vez. Deve ser maior que 0 e menor ou igual a 100000.

Este parâmetro está disponível tanto em tempo de execução quanto na inicialização:

• Para definir o parâmetro em tempo de execução, utilize o comando setParameter

• Para definir o parâmetro na inicialização, use a configuração setParameter

Este exemplo define queryAnalysisWriterMaxBatchSize como 1000 na inicialização de uma instância mongod :

mongod --setParameter queryAnalysisWriterMaxBatchSize=1000

Durante o tempo de execução, você também pode configurar o parâmetro com o comando setParameter :

db.adminCommand( { setParameter: 1, queryAnalysisWriterMaxBatchSize: 1000 } )