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.

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

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.

KeysRotationIntervalSec

Novidade na versão 3.6.

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

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 para mongod e mongos.

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 para mongod e mongos.

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 para mongod e mongos.

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

Para uso com MongoDB usando Autorização LDAP em sistemas autogerenciados. Disponível somente para instâncias mongod .

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.

ldapUseConnectionPool

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

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

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

Novidades na versão 4.2.1.

Alterado a partir das versões 5.0.9do MongoDB Valor padrão 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

Novidades na versão 4.2.1.

Alterado a partir das versões 5.0.9do MongoDB Valor padrão 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

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

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.

maxValidateMemoryUsageMB

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

ocspEnabled

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

Dica

Veja também:

• ocspValidationRefreshPeriodSecs

• tlsOCSPStaplingTimeoutSecs

• tlsOCSPVerifyTimeoutSecs

ocspValidationRefreshPeriodSecs

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

Novidade na versão 3.6.

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

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

Novidade na versão 3.6.

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

Observação

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

Disponível para mongod e mongos.

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

Padrão: 10000

Disponível para mongod e mongos.

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

Padrão: 15000

Disponível para mongod e mongos.

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

tlsOCSPStaplingTimeoutSecs

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

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

Padrão: 30

Disponível apenas para mongos.

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

Padrão: 0

Disponível para mongod e mongos.

Novidade na versão 3.4.

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

Padrão: true

Disponível para mongod e mongos.

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

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

connPoolMaxConnsPerHost

Padrão: 200

Disponível para mongod e mongos.

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

Novidades na versão 3.6.3.

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

Novidades na versão 3.6.3.

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

Padrão: 600000 (10 minutos)

Disponível para mongod e mongos.

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 Avaliar Desempenho das Operações Atuais e Otimizar Desempenho de Query e usar o parâmetro logLevel , mongostat e profiling.

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

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 de produção do mongod com o ttlMonitorEnabled desabilitado, exceto sob orientação do suporte do MongoDB. Impedir a remoção de documento TTL pode impactar negativamente as operações internas do sistema MongoDB que dependem de í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

maxIndexBuildMemoryUsageMegabytes

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 do usuário, como Criar Índice , ou por um processo administrativo, como uma sincronização inicial. Ambos estão sujeitos ao limite definido por maxIndexBuildMemoryUsageMegabytes.

Uma operação de 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 em vários bancos de dados simultaneamente e potencialmente consumir uma quantidade de memória maior do que o limite definido em 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

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 negativo no desempenho; 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 se journaling estiver habilitado

• 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 Watchdog do nó de armazenamento não tiver sido ativado no momento da inicialização.

tcmallocAggressiveMemoryDecommit

Tipo: número inteiro (somente 0 ou 1)

Padrão: 0

Se você habilitar o tcmallocAggressiveMemoryDecommit, MongoDB:

• libera um pedaço de memória para o sistema e

• tenta retornar todos os pedaços livres vizinhos.

Um valor de 1 habilita tcmallocAggressiveMemoryDecommit; 0 desabilita este parâmetro.

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ê ativar este parâmetro, o sistema exigirá novas alocações de memória para uso. Considere habilitar tcmallocAggressiveMemoryDecommit apenas em sistemas com restrição de memória e depois de buscar outras opções de memória e desempenho.

Apesar da possível degradação do desempenho com o uso de tcmallocAggressiveMemoryDecommit, ele é frequentemente preferido em relação ao uso de tcmallocReleaseRate.

tcmallocReleaseRate

Padrão: 1.0

Especifica a taxa de versão tcmalloc (TCMALLOC_RELEASE_RATE). De acordo com https://gperftools.github.io/gperftools/tcmalloc.html#runtime, TCMALLOC_RELEASE_RATE é descrito como a "taxa na qual liberamos memória não utilizada para o sistema, via madvise(MADV_DONTNEED), em sistemas compatíveis. Zero significa que nunca liberamos memória de volta para o sistema. Aumente este sinalizador para retornar a memória mais rapidamente. Diminua-o para retornar a memória mais lentamente. As taxas razoáveis estão na faixa [0,10]."

Observação

Considere usar tcmallocAggressiveMemoryDecommit em vez de tcmallocReleaseRate, a menos que você observe uma degradação significativa do desempenho ao usar tcmallocAggressiveMemoryDecommit.

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 setParameter; por exemplo:

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

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

mongod --setParameter "tcmallocReleaseRate=5.0"

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

• 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

Novidade na versão 3.4.

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 maxLogSizeKB e o conteúdo do campo de impostos específicos ultrapassa esse limite, mantendo a formatação JSON válida. Os inteiros de log que contêm atributos truncados anexam um objeto truncated ao final da entrada de registro.

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

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

Novidade na versão 3.4.

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

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} )

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

Novo na versão 3.2.

Alterado na versão 3.4.14: 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

Novidades na versão 3.4.14.

Tipo: string

Disponível apenas para mongos.

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

Importante

Se o mongos não puder criar o diretório especificado, a captura de dados de diagnóstico será desabilitada para esta instância. Isso geralmente é causado por:

• um arquivo com o mesmo nome já existe no caminho, ou

• o processo não tem 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

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.

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

Novo na versão 3.2.

Alterado na versão 3.4.14: 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

Novo na versão 3.2.

Alterado na versão 3.4.14: 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 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

Para permitir alterações de configuração utilizando endereços IP, configure disableSplitHorizonIPCheck=true utilizando o arquivo de configuração do nó:

setParameter:
   disableSplitHorizonIPCheck: true

Se você tentar atualizar o disableSplitHorizonIPCheck no tempo de execução, o db.adminCommand() retornará um erro:

db.adminCommand( { setParameter: 1, "disableSplitHorizonIPCheck": true } )
MongoServerError: not allowed to change [disableSplitHorizonIPCheck] at runtime

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

Novidade na versão 3.6.

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

Novidade na versão 3.6.

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

Novidade na versão 5.0.10.

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 de oplogBatchDelayMillis faz com que o MongoDB aplique lotes de oplog com menos frequência em secundários, com cada lote contendo quantidades maiores de dados. Isso reduz IOPS em secundários, mas aumenta latência para escritas com referência de escrita "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: false

Determina se os documentos temporários necessários para comandos findAndModify repetíveis são armazenados na coleção lateral (image_collection no banco de dados de configuração).

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

Novidade na versão 3.6.

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

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

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

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

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.

maxNumSyncSourceChangesPerHour

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

Novidade na versão 3.6.

Tipo: inteiro

Padrão: 60

Disponível apenas para mongod.

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

Novo na versão 3.2.

Tipo: inteiro

Padrão: 16

Disponível apenas para mongod.

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.

Tipo: inteiro

Padrão: 0

Disponível apenas para mongod.

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

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

Novidade na versão 3.6.

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

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 que os arquivos de rollback não sejam criados:

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.

Novidades na versão 4.4.

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 } } )

Parâmetros de fragmentação

balancerMigrationsThrottlingMs

Novidades na versão 5.0.18.

Tipo: inteiro

Padrão: 1000

Disponível apenas para mongod.

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 } )

chunkMigrationConcurrency

Disponível a partir do MongoDB 5.0.15.

Tipo: inteiro

Padrão: 1

Disponível apenas para mongod.

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 Migração e replicação de chunks.

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 } )

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 chunk'ranges contendo :term:'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

Novidade na versão 5.0.10.

Tipo: booleano

Padrão: false

Disponível apenas para mongos.

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

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

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 do moveChunk , especifica a porcentagem máxima de dados não transferidos permitidos pelo protocolo de migração (expresso em porcentagem do tamanho total do chunk) para fazer 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.

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

mongod --setParameter 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)

Tipo: inteiro

Padrão: 500

Disponível apenas para mongod.

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 } )

readHedgingMode

Disponível apenas para mongos.

Tipo: string

Padrão: ativado

Especifica se o mongos suporta leituras com hedge para estas operações de leitura cuja preferência de leitura habilitou a opção de leitura com hedge.

Os valores disponíveis são:

Valor	Descrição
on	A instância do mongos suporta leituras com hedge para operações de leitura cuja preferência de leitura habilitou a opção de leitura com hedge.
off	A instância mongos não permite leituras protegidas. Ou seja, as leituras distribuídas estão indisponíveis, mesmo para operações de leitura cuja read preference tenha habilitado a opção de leitura distribuída.

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 desativar a compatibilidade de leituras distribuídas para uma instância do mongos, você pode emitir o seguinte durante a inicialização:

mongos --setParameter readHedgingMode=off

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

db.adminCommand( { setParameter: 1, readHedgingMode: "off" } )

Dica

Veja também:

• Leituras cobertas

• maxTimeMSForHedgedReads

routingTableCacheChunkBucketSize

Novidades na versão 5.0.21.

Disponível para mongod e mongos.

Tipo: inteiro

Padrão: 500

Especifica o tamanho dos buckets de cache da tabela de roteamento usados para implementar a otimização de agrupamento de chunks. Deve ser maior ou igual a 0.

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 tamanho do bucket de chunk de cache para 250 em um mongod, emita o seguinte comando na inicialização:

mongod --setParameter routingTableCacheChunkBucketSize=1000

shutdownTimeoutMillisForSignaledShutdown

Novidades na versão 5.0.

Tipo: inteiro

Padrão: 15000

Disponível apenas para mongod.

Especifica o tempo (em milissegundos) para aguardar a conclusão de qualquer operação de banco de dados em andamento antes de iniciar um desligamento demongod em resposta a um sinal de SIGTERM.

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 tempo para 250 milissegundos, você pode emitir o seguinte durante a inicialização:

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

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

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

mongosShutdownTimeoutMillisForSignaledShutdown

Novidades na versão 5.0.

Tipo: inteiro

Padrão: 15000

Disponível apenas para mongos.

Especifica o tempo (em milissegundos) para aguardar a conclusão de qualquer operação de banco de dados em andamento antes de iniciar um desligamento demongos em resposta a um sinal de SIGTERM.

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 tempo para 250 milissegundos, você pode emitir o seguinte durante a inicialização:

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

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

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

ShardingTaskExecutorPoolHostTimeoutMS

Tipo: número inteiro

Padrão: 300.000 (5 minutos)

Disponível para mongod e mongos.

Tempo máximo que mongos passa sem comunicação com um host antes que mongoscancele todas as conexões com o host.

Se definido, ShardingTaskExecutorPoolHostTimeoutMS deve ser maior que a soma de ShardingTaskExecutorPoolRefreshRequirementMS e ShardingTaskExecutorPoolRefreshTimeoutMS. Caso contrário, mongos ajusta o valor de ShardingTaskExecutorPoolHostTimeoutMS para ser maior que a soma.

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 ShardingTaskExecutorPoolHostTimeoutMS como 120000 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolHostTimeoutMS: 120000 } )

ShardingTaskExecutorPoolMaxConnecting

Novidade na versão 3.6.

Tipo: número inteiro

Padrão: 2

Disponível para mongod e mongos.

Número máximo de conexões iniciando simultaneamente (incluindo conexões pendentes no estado de configuração/atualização) que cada pool de conexões TaskExecutor pode ter com uma instância mongod. Você pode definir esse parâmetro para controlar a taxa na qual mongos adiciona conexões a uma instânciamongod.

Se definido, ShardingTaskExecutorPoolMaxConnecting deve ser menor ou igual a ShardingTaskExecutorPoolMaxSize. Se for maior, mongos ignora o valor ShardingTaskExecutorPoolMaxConnecting.

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 ShardingTaskExecutorPoolMaxConnecting como 20 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

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

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

ShardingTaskExecutorPoolMaxSize

Tipo: número inteiro

Padrão: 2 ⁶⁴ - 1

Disponível para mongod e mongos.

Número máximo de conexões de saída que cada pool de conexões TaskExecutor pode abrir para qualquer instância mongod específica. O máximo de conexões possíveis a um determinado host em todos os pools do TaskExecutor é:

ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

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 ShardingTaskExecutorPoolMaxSize como 20 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolMaxSize=20

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

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

mongos pode ter até n pools de conexão do TaskExecutor, em que n é o número de núcleos. Consulte a página taskExecutorPoolSize.

Dica

Veja também:

ShardingTaskExecutorPoolMinSize

ShardingTaskExecutorPoolMaxSizeForConfigServers

Novidade na versão 5.0.10.

Tipo: número inteiro

Padrão: -1

Disponível para mongod e mongos.

Substituição opcional de ShardingTaskExecutorPoolMaxSize para definir o número máximo de conexões de saída que cada pool de conexões do TaskExecutor pode abrir para um servidor de configuração.

Quando definido como:

• -1, ShardingTaskExecutorPoolMaxSize é usado. Este é o padrão.

• um valor inteiro maior que -1, substitui o número máximo de conexões de saída que cada pool de conexões do TaskExecutor pode abrir para um servidor de configuração.

O parâmetro só se aplica a sistemas fragmentados.

O exemplo a seguir define ShardingTaskExecutorPoolMaxSize como 2 durante a inicialização, o que define o número máximo de conexões de saída que cada pool de conexões do TaskExecutor pode abrir para um servidor de configuração como 2:

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 ShardingTaskExecutorPoolMaxSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolMinSize

Tipo: número inteiro

Padrão: 1

Disponível para mongod e mongos.

Número mínimo de conexões de saída que cada pool de conexões TaskExecutor pode abrir para qualquer instância mongod específica.

ShardingTaskExecutorPoolMinSize as conexões são criadas na primeira vez que uma conexão com um novo host é solicitada do pool. Enquanto o pool estiver ocioso, ele manterá esse número de conexões até que passem ShardingTaskExecutorPoolHostTimeoutMS milissegundos sem que nenhum aplicativo use esse pool.

No caso de um mongos usando o parâmetro warmMinConnectionsInShardingTaskExecutorPoolOnStartup, o parâmetro ShardingTaskExecutorPoolMinSize também controla quantas conexões para cada host de fragmento são estabelecidas na inicialização da instância mongos antes de começar a aceitar conexões de cliente de entrada.

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 ShardingTaskExecutorPoolMinSize como 2 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

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

mongos pode ter até n pools de conexão do TaskExecutor, em que n é o número de núcleos. Consulte a página taskExecutorPoolSize.

Dica

Veja também:

• ShardingTaskExecutorPoolMaxSize

• warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolMinSizeForConfigServers

Novidade na versão 5.0.10.

Tipo: número inteiro

Padrão: -1

Disponível para mongod e mongos.

Substituição opcional de ShardingTaskExecutorPoolMinSize para definir o número mínimo de conexões de saída que cada pool de conexões do TaskExecutor pode abrir para um servidor de configuração.

Quando definido como:

• -1, ShardingTaskExecutorPoolMinSize é usado. Este é o padrão.

• um valor inteiro maior que -1, substitui o número mínimo de conexões de saída que cada pool de conexão do TaskExecutor pode abrir para um servidor de configuração.

O parâmetro só se aplica a sistemas fragmentados.

O exemplo a seguir define ShardingTaskExecutorPoolMinSize como 2 durante a inicialização, o que define o número mínimo de conexões de saída que cada pool de conexões do TaskExecutor pode abrir para um servidor de configuração como 2:

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 ShardingTaskExecutorPoolMinSizeForConfigServers=2

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

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

ShardingTaskExecutorPoolRefreshRequirementMS

Tipo: número inteiro

Padrão: 60.000 (1 minuto)

Disponível para mongod e mongos.

Tempo máximo que o mongos aguarda antes de tentar fazer o heartbeat de uma conexão ociosa no pool.

Se definido, ShardingTaskExecutorPoolRefreshRequirementMS deve ser maior que ShardingTaskExecutorPoolRefreshTimeoutMS. Caso contrário, mongos ajusta o valor de ShardingTaskExecutorPoolRefreshTimeoutMS para ser menor que ShardingTaskExecutorPoolRefreshRequirementMS.

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 ShardingTaskExecutorPoolRefreshRequirementMS como 90000 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshRequirementMS: 90000 } )

ShardingTaskExecutorPoolRefreshTimeoutMS

Tipo: número inteiro

Padrão: 20.000 (20 segundos)

Disponível para mongod e mongos.

Tempo máximo que o mongos espera por um batimento cardíaco antes de cronometrar o batimento cardíaco.

Se definido, ShardingTaskExecutorPoolRefreshTimeoutMS deve ser menor que ShardingTaskExecutorPoolRefreshRequirementMS. Caso contrário, mongos ajusta o valor de ShardingTaskExecutorPoolRefreshTimeoutMS como inferior a ShardingTaskExecutorPoolRefreshRequirementMS.

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 ShardingTaskExecutorPoolRefreshTimeoutMS como 30000 durante a inicialização:

mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

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

db.adminCommand( { setParameter: 1, ShardingTaskExecutorPoolRefreshTimeoutMS: 30000 } )

ShardingTaskExecutorPoolReplicaSetMatching

Alterado na versão 5.0.

Disponível para mongod e mongos.

Tipo: string

Padrão: "automático"

Em uma instância do mongos, esse parâmetro define a política que determina o limite de tamanho mínimo de seus pools de conexão para nós dentro dos conjuntos de réplicas.

Em uma instância mongod, esse parâmetro define a diretiva que determina o limite de tamanho mínimo de seus pools de conexões para nós dentro de outros conjuntos de réplicas.

Observe que esse parâmetro gerencia apenas conexões para operações diretamente relacionadas a solicitações de usuários e operações CRUD.

Os valores disponíveis são:

Política de correspondência	Descrição
"automatic" (Padrão)	A partir de 5.0, "automatic" é o novo valor padrão. Quando configurado para um mongos, a instância segue o comportamento especificado para a opção "matchPrimaryNode". Quando configurado para um mongod, a instância segue o comportamento especificado para a opção "disabled". AVISO: se o estiver definido ShardingTaskExecutorPoolReplicaSetMatching como "automatic", o ainda descreverá a política real que está sendo usada,replicaSetMatchingStrategy não "automatic". Para localizar o valor do ShardingTaskExecutorPoolReplicaSetMatching, utilize que retorna o valor do parâmetro do servidor getParameter .
"matchPrimaryNode"	Quando definido para um mongos, o limite de tamanho mínimo do pool de conexões da instância para cada secundário de um conjunto de réplicas no cluster fragmentado (especificamente, conjunto de réplicas de estilhaços e servidores de configuração) é igual ao tamanho de seu pool de conexões para o primário desse conjunto de réplicas. Quando definido para mongod, o limite mínimo de tamanho do pool de conexões da instância para cada secundário de outro conjunto de réplicas no cluster fragmentado (especificamente, conjunto de réplicas fragmentadas e servidores de configuração) é igual ao tamanho do pool de conexões para o primário desse conjunto de réplicas. AVISO: se vários servidores de fragmentos em sua topologia puderem sofrer um rápido influxo de operações entre fragmentos, não defina essa opção em suas mongod instâncias. No caso de uma redução primária, matchPrimaryNode garante que qualquer secundário que se torne o primário possa lidar com o nível atual de leituras e gravações primárias.
"matchBusiestNode"	Quando definido para um mongos, o limite de tamanho mínimo da instância do pool de conexões para cada membro de um conjunto de réplicas no cluster fragmentado (especificamente, conjunto de réplicas de estilhaços e servidores de configuração) é igual ao maior entre as contagens de conexão ativas para o primário e cada membro secundário desse conjunto de réplicas. Quando definido para um mongod, o limite de tamanho mínimo da instância do pool de conexões para cada membro de outro conjunto de réplicas no cluster fragmentado (especificamente, conjunto de réplicas shard e servidores de configuração) é igual ao maior entre as contagens de conexão ativas para o primary e cada membro secundário desse conjunto de réplicas. Com "matchBusiestNode", mongos mantém conexões suficientes com cada secundário para lidar com o nível atual de leituras e gravações primárias e secundárias. O número de conexões a serem mantidas no pool diminui à medida que o número de conexões ativas diminui.
"disabled"	Quando definido para um , o número mínimo de conexões da instância no pool de conexões da instância para cada nó de um conjunto de réplicas no clusterv fragmentado (especificamente, conjunto de réplicas de shard e servidores de configuração) é igual mongos ao ShardingTaskExecutorPoolMinSize. Quando definido para um , o número mínimo de conexões da instância no pool de conexões da instância para cada nó de outro conjunto de réplicas no cluster fragmentado (especificamente, conjunto de réplicas de shard e servidores de configuração) é igual mongod ao ShardingTaskExecutorPoolMinSize.

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 ShardingTaskExecutorPoolReplicaSetMatching como "automatic" durante a inicialização:

mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"

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

db.adminCommand( { setParameter: 1,  ShardingTaskExecutorPoolReplicaSetMatching: "automatic" } )

taskExecutorPoolSize

Tipo: número inteiro

Padrão: 1

Disponível apenas para mongos.

O número de grupos de conexão do Task Executor para utilizar para um determinado mongos.

Se o valor do parâmetro for 0 ou menos, o número de pools de conexão do Executor de tarefas será o número de núcleos, com as seguintes exceções:

• Se o número de núcleos for menor que 4, o número de grupos de conexão do Executor de Tarefa será 4.

• Se o número de núcleos for maior que 64, o número de pools de conexão do Executor de tarefas será 64.

Importante

Antes de modificar o taskExecutorPoolSize valor do no Linux, consulte um professional de Suporte do MongoDB . A modificação deste parâmetro pode causar regressões de desempenho.

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 taskExecutorPoolSize=6

Dica

Veja também:

• ShardingTaskExecutorPoolMaxSize

• ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup

Disponível apenas para mongos.

Tipo: booleano

Padrão: true

Configura uma instância mongos para pré-carregar a tabela de roteamento de um cluster fragmentado na inicialização. Com essa configuração habilitada, o mongos armazena em cache a tabela de roteamento de todo o cluster para cada collection fragmentada como parte de seu procedimento de inicialização, antes de começar a aceitar conexões de clientes.

Sem essa configuração habilitada, o mongos carrega apenas uma tabela de roteamento conforme necessário para conexões de cliente de entrada e carrega apenas a tabela de roteamento específica para o namespace de uma determinada solicitação.

Uma instância mongos com o parâmetro loadRoutingTableOnStartup ativado pode ter tempos de inicialização mais longos, mas resultará em uma manutenção mais rápida das conexões iniciais do cliente depois de iniciada.

loadRoutingTableOnStartup está habilitado por padrão.

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

warmMinConnectionsInShardingTaskExecutorPoolOnStartup

Disponível apenas para mongos.

Tipo: booleano

Padrão: true

Disponível apenas para mongos.

Configura uma instância do mongos para pré-aquecer seu pool de conexão na inicialização. Com esse parâmetro ativado, o mongos tenta estabelecer ShardingTaskExecutorPoolMinSize conexões de rede com cada servidor de fragmentos como parte de seu procedimento de inicialização, antes de começar a aceitar conexões de clientes.

Um timeout para este comportamento pode ser configurado com o parâmetro warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS. Se esse tempo limite for atingido, o mongos começará a aceitar conexões de cliente, independentemente do tamanho de seu pool de conexões.

Uma instância mongos com esse parâmetro ativado pode ter tempos de inicialização mais longos, mas resultará em uma manutenção mais rápida das conexões iniciais do cliente depois de iniciada.

warmMinConnectionsInShardingTaskExecutorPoolOnStartup está habilitado por padrão.

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

Dica

Veja também:

• warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

• ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

Disponível apenas para mongos.

Tipo: número inteiro

Padrão: 2000 (2 segundos)

Disponível apenas para mongos.

Define o limite de tempo limite em milissegundos para que um mongos aguarde o estabelecimento de ShardingTaskExecutorPoolMinSize conexões por host de fragmento ao usar o parâmetro warmMinConnectionsInShardingTaskExecutorPoolOnStartup. Se esse tempo limite for atingido, o mongos começará a aceitar conexões de clientes, independentemente do tamanho de seu pool de conexões.

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

Dica

Veja também:

• warmMinConnectionsInShardingTaskExecutorPoolOnStartup

• ShardingTaskExecutorPoolMinSize

migrateCloneInsertionBatchDelayMS

Disponível apenas para mongod.

Tipo: número inteiro não negativo

Padrão: 0

Tempo em milissegundos para esperar entre lotes de inserções durante a etapa de clonagem do processo de migração. Essa espera é adicional ao secondaryThrottle.

O valor padrão 0 indica nenhuma espera adicional.

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 define o migrateCloneInsertionBatchDelayMS para 200 milissegundos:

mongod --setParameter migrateCloneInsertionBatchDelayMS=200

O parâmetro também pode ser configurado utilizando o comando setParameter:

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

migrateCloneInsertionBatchSize

Disponível apenas para mongod.

Tipo: número inteiro não negativo

Padrão: 0

O número máximo de documentos a inserir em um único lote durante a etapa de clonagem do processo de migração.

O valor padrão de 0 não indica nenhum número máximo de documentos por lote. No entanto, na prática, isso resulta em lotes que contêm até 16 MB de documentos.

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 define migrateCloneInsertionBatchSize para 100 documentos:

mongod --setParameter migrateCloneInsertionBatchSize=100

O parâmetro também pode ser configurado utilizando o comando setParameter:

db.adminCommand( { setParameter: 1, migrateCloneInsertionBatchSize: 100 } )

orphanCleanupDelaySecs

Novidade na versão 3.6.

Padrão: 900 (15 minutos)

Disponível apenas para mongod.

Atraso mínimo antes que um chunk migrado seja excluído do shard de origem.

Antes de excluir a parte durante a migração de parte, o MongoDB aguarda que orphanCleanupDelaySecs ou que queries em andamento envolvendo a parte sejam concluídas no fragmento primário, o que for mais demorado.

No entanto, como o primário do fragmento não tem conhecimento das queries em andamento nos secundários do fragmento, as queries que usam a parte, mas são executadas em secundários, podem ver os documentos desaparecerem se essas queries demorarem mais do que as queries do primário do fragmento e do orphanCleanupDelaySecs.

Observação

Esse comportamento afeta apenas as queries em andamento que começam antes da migração em partes. As queries que iniciam após o início da migração do bloco não utilizarão o bloco migratório.

Se um fragmento tiver restrições de armazenamento, considere reduzir esse valor temporariamente. Se executar queries que excedam 15 minutos em segundo plano, considere aumentar esse valor.

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 define o orphanCleanupDelaySecs em 20 minutos:

mongod --setParameter orphanCleanupDelaySecs=1200

Isto também pode ser configurado utilizando o comando setParameter:

db.adminCommand( { setParameter: 1, orphanCleanupDelaySecs: 1200 } )

persistedChunkCacheUpdateMaxBatchSize

Novidades na versão 5.0.25.

Disponível apenas para mongod.

Tipo: inteiro

Padrão: 1000

Para rotear e atender às operações, os shards devem conhecer as informações de roteamento e propriedade associadas às suas coleções. Essas informações são propagadas do nó primário de um fragmento para seus nós secundários por meio da replicação das coleções de cache internas config.cache.collections e config.cache.chunks.<collectionName>.

Em versões anteriores, as atualizações na coleção de cache de partes eram executadas individualmente (o que significa que uma entrada era excluída e uma nova entrada era inserida). A partir do MongoDB 5.0.25, estas atualizações são executadas como um lote de exclusões seguido por um lote de inserções. A lógica atualizada melhora o desempenho das coleções que contêm um grande número de partes.

O parâmetro persistedChunkCacheUpdateMaxBatchSize especifica o tamanho máximo do lote utilizado para atualizar o cache de chunk persistente.

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 exemplo define persistedChunkCacheUpdateMaxBatchSize para 700 na inicialização:

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

Você também pode configurar o persistedChunkCacheUpdateMaxBatchSize durante o tempo de execução:

db.adminCommand( { setParameter: 1, persistedChunkCacheUpdateMaxBatchSize: 700 } )

rangeDeleterBatchDelayMS

Disponível apenas para mongod.

Tipo: número inteiro não negativo

Padrão: 20

A quantidade de tempo, em milissegundos, a aguardar antes do próximo lote de exclusão durante o estágio de limpeza da migração de blocos (ou o comando cleanupOrphaned ).

No MongoDB 3.4, considere se _secondaryThrottle está definido antes de modificar o rangeDeleterBatchDelayMS. No MongoDB 3.4, o atraso de replicação _secondaryThrottle ocorre após cada exclusão de documento em vez de após a exclusão em lote.

No MongoDB 3.6+, o atraso de replicação _secondaryThrottle ocorre após cada exclusão em lote.

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 define o rangeDeleterBatchDelayMS para 200 milissegundos:

mongod --setParameter rangeDeleterBatchDelayMS=200

O parâmetro também pode ser configurado utilizando o comando setParameter:

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

rangeDeleterBatchSize

Disponível apenas para mongod.

Tipo: número inteiro não negativo

Padrão: 2147483647 a partir do MongoDB 5.0.6

O número máximo de documentos em cada lote a serem excluídos durante o estágio de limpeza da migração de blocos (ou o comando cleanupOrphaned ).

Um valor de 0 indica que o sistema escolhe o valor 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

O exemplo a seguir define rangeDeleterBatchSize para 32 documentos:

mongod --setParameter rangeDeleterBatchSize=32

O parâmetro também pode ser configurado utilizando o comando setParameter:

db.adminCommand( { setParameter: 1, rangeDeleterBatchSize: 32 } )

skipShardingConfigurationChecks

Novidades na versão 3.6.3.

Disponível apenas para mongod.

Tipo: booleano

Padrão: falso

Quando true, permite iniciar um membro do estilhaço ou membro do servidor de configuração como autônomo para operações de manutenção. Este parâmetro é mutuamente exclusivo com as opções --configsvr ou --shardsvr.

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

mongod --setParameter skipShardingConfigurationChecks=true

Importante

Após completar a manutenção, remova o parâmetro skipShardingConfigurationChecks ao reiniciar o mongod.

findChunksOnConfigTimeoutMS

Novidades na versão 5.0.

Disponível para mongod e mongos.

Tipo: número inteiro não negativo

Padrão: 900.000

O timeout em milissegundos para localizar operações em chunks.

Se houver um grande número de blocos no cluster e o carregamento de blocos falhar com o erro ExceededTimeLimit, aumente o valor do parâmetro:

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

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 do health manager

activeFaultDurationSecs

Tipo: documento

Disponível apenas para mongos.

O tempo de espera de uma falha do health manager até que o mongos seja removido do cluster, em segundos.

Quando uma falha é detectada e um Health Manager é configurado como critical, o servidor espera pelo intervalo especificado antes de remover o mongos do agrupamento.

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 a duração de falha para cinco minutos, emita o seguinte na inicialização:

mongos --setParameter activeFaultDurationSecs=300

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

db.adminCommand(
  {
      setParameter: 1,
      activeFaultDurationSecs: 300
  }
)

Os parâmetros configurados com setParameter não persistem entre reinicializações. Consulte a página setParameter para obter detalhes.

Para tornar essa configuração persistente, defina activeFaultDurationSecs em seu arquivo de configuração do mongos usando a opção setParameter, como no exemplo a seguir:

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

Tipo: array de documentos

Disponível apenas para mongos.

Use este parâmetro para definir os níveis de intensidade para health managers.

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

healthMonitoringIntensities aceita uma série de documentos, values. Cada documento no values tem dois campos:

• type, a faceta do Health Manager

• intensity, o nível de intensidade

Health managers

Facet	O que o observador de integridade verifica
configServer	Problemas de integridade do cluster relacionados à conectividade com o servidor de configuração.
dns	Problemas de integridade do cluster relacionados à disponibilidade e funcionalidade de DNS.
ldap	Problemas de integridade do cluster relacionados à disponibilidade e funcionalidade do LDAP.

Níveis de intensidade

Nível de intensidade	Descrição
critical	O gerenciado de integridade nessa faceta está habilitado e tem a capacidade de mover os mongos com falha para fora do cluster se ocorrer um erro. O gerenciador de integridade espera o tempo especificado por activeFaultDurationSecs antes de parar e mover os mongos para fora do cluster automaticamente.
non-critical	O health manager nesta facet está habilitado e registra erros, mas o mongos permanece no cluster se forem encontrados erros.
off	O health manager nesta facet está desabilitado. O mongos não realiza nenhuma verificação de integridade nesta facet. Este é o nível de intensidade padrão.

Por exemplo, para definir dns Health Manager facet para o nível de intensidade critical, emita o seguinte na inicialização:

mongos --setParameter 'healthMonitoringIntensities={ values:[ { type:"dns", intensity: "critical"} ] }'

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

db.adminCommand(
  {
      setParameter: 1,
      healthMonitoringIntensities: { values: [ { type: "dns", intensity: "critical" } ] } } )
  }
)

Os parâmetros configurados com setParameter não persistem entre reinicializações. Consulte a página setParameter para obter detalhes.

Para tornar essa configuração persistente, defina healthMonitoringIntensities em seu arquivo de configuração do mongos usando a opção setParameter, como no exemplo a seguir:

setParameter:
   healthMonitoringIntensities: "{ values:[ { type:\"dns\", intensity: \"critical\"} ] }"

healthMonitoringIntervals

Tipo: array de documentos

Disponível apenas para mongos.

A frequência com que este health manager será executado, em milissegundos.

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

healthMonitoringIntervals aceita uma série de documentos, values. Cada documento no values tem dois campos:

• type, a faceta do Health Manager

• interval, o intervalo de tempo em que ele é executado, em milissegundos

Health managers

Facet	O que o observador de integridade verifica
configServer	Problemas de integridade do cluster relacionados à conectividade com o servidor de configuração.
dns	Problemas de integridade do cluster relacionados à disponibilidade e funcionalidade de DNS.
ldap	Problemas de integridade do cluster relacionados à disponibilidade e funcionalidade do LDAP.

Por exemplo, para definir a ldap Health Manager facet para executar verificações de integridade a cada 30 segundos, execute o seguinte na inicialização:

mongos --setParameter 'healthMonitoringIntervals={ values:[ { type:"ldap", interval: "30000"} ] }'

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

db.adminCommand(
  {
      setParameter: 1,
      healthMonitoringIntervals: { values: [ { type: "ldap", interval: "30000" } ] } } )
  }
)

Os parâmetros configurados com setParameter não persistem entre reinicializações. Consulte a página setParameter para obter detalhes.

Para tornar essa configuração persistente, defina healthMonitoringIntervals em seu arquivo de configuração do mongos usando a opção setParameter, como no exemplo a seguir:

setParameter:
   healthMonitoringIntervals: "{ values: [{type: \"ldap\", interval: 200}] }"