Los parámetros de MongoDB Server para una implementación autogestionada

Parámetros de autenticación

allowRolesFromX509Certificates

Disponible tanto para mongod como para mongos.

Por defecto: true

Un indicador booleano que permite o impide la recuperación de roles de autorización de los certificados del cliente X.509.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

authenticationMechanisms

Disponible tanto para mongod como para mongos.

Especifica la lista de mecanismos de autenticación que acepta el servidor. Establézcalo en uno o más de los siguientes valores. Si especifica varios valores, utilice una lista separada por comas y sin espacios. Para obtener descripciones de los mecanismos de autenticación, consulte Autenticación en implementaciones autogestionadas.

Valor	Descripción
SCRAM-SHA-1	RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-1.
SCRAM-SHA-256	RFC 7677 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-256.
MONGODB-X509	Autenticación de certificados TLS/SSL de MongoDB.
GSSAPI (Kerberos)	Autenticación externa utilizando Kerberos. Este mecanismo está disponible solo en MongoDB Enterprise.
PLAIN (SASL LDAP)	Autenticación externa mediante LDAP. También puede utilizar PLAIN para autenticar a los usuarios de base de datos. PLAIN transmite las contraseñas en texto sin cifrar. Este mecanismo está disponible solo en MongoDB Enterprise.
MONGODB-OIDC	OpenID Connect es una capa de autenticación compilada sobre OAuth2. Este mecanismo está disponible solo en MongoDB Enterprise.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para especificar tanto PLAIN como SCRAM-SHA-256 como mecanismos de autenticación, utilice el siguiente comando:

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

authFailedDelayMs

Disponible tanto para mongod como para mongos.

Por defecto: 0

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

El número de milisegundos que se debe esperar antes de informar a los clientes de que su intento de autenticación ha fallado. Este parámetro puede estar en el rango de 0 a 5000, inclusive.

Establecer este parámetro hace que los ataques de inicio de sesión por fuerza bruta en una base de datos sean más lentos. Sin embargo, los clientes que esperan una respuesta del servidor MongoDB siguen consumiendo recursos del servidor, lo que puede afectar negativamente a los intentos de inicio de sesión benignos si el servidor niega el acceso a muchos otros clientes al mismo tiempo.

awsSTSRetryCount

Cambiado en la versión 7.0: (También a partir de 6.0.7 y 5.0.18)

En versiones anteriores, la autenticación de AWS IAM se reintentaba solo cuando el servidor devolvía un error HTTP 500.

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 2

Para implementaciones de MongoDB que utilizan credenciales de AWS IAM o variables de entorno de AWS IAM.

Número máximo de reintentos de autenticación de AWS IAM tras un fallo de conexión.

En el siguiente ejemplo se establece awsSTSRetryCount en 15 reintentos:

mongod --setParameter awsSTSRetryCount=15

Alternativamente, los siguientes ejemplos utilizan el comando setParameter dentro de mongosh:

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

clusterAuthMode

Disponible tanto para mongod como para mongos.

Configure el clusterAuthMode a sendX509 o x509. Útil durante la actualización continua para usar x509 para la autenticación de membresía para minimizar el tiempo de inactividad.

Para obtener más información sobre TLS/SSL y MongoDB, consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autogestionadas y Configuración de TLS/SSL para clientes .

Este parámetro solo está disponible en tiempo de ejecución. Para establecer el parámetro, utilice el comando setParameter.

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

enableLocalhostAuthBypass

Disponible tanto para mongod como para mongos.

Por defecto: true

Especifique 0 o false para desactivar la omisión de autenticación de localhost. Activado por defecto.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Consulte la Excepción de Localhost en implementaciones autogestionadas para obtener más información.

enforceUserClusterSeparation

Disponible tanto para mongod como para mongos.

Establezca en false para desactivar la comprobación de O/OU/DC cuando clusterAuthMode esté keyFile en su archivo de configuración. Esto permite que los clientes que poseen certificados de nodo se autentiquen como usuarios almacenados en la base de datos $external. El servidor no se iniciará si clusterAuthMode no está keyFile en su archivo de configuración.

Para establecer el parámetro enforceUserClusterSeparation en false, ejecute el siguiente comando durante el inicio:

mongod --setParameter enforceUserClusterSeparation=false

JWKSMinimumQuiescePeriodSecs

Disponible tanto para mongod como para mongos.

Por defecto: 60 segundos (1 minuto)

Especifica el período de tiempo mínimo que debe transcurrir entre las solicitudes sucesivas al punto final JWKSetURI de un proveedor de identidad determinado. Si una llave pública RSA se cambia varias veces durante el período de inactividad, es posible que esa llave no funcione como se esperaba hasta durante un minuto, a menos que el período de inactividad se reduzca manualmente. Si este parámetro se establece en cero, no hay período de inactividad y la llave se puede actualizar repetidamente.

Este parámetro está disponible tanto en el inicio como en el tiempo de ejecución. Para establecer el parámetro, utiliza la configuración setParameter.

KeysRotationIntervalSec

Disponible tanto para mongod como para mongos.

Por defecto: 7776000 segundos (90 días)

Especifica el número de segundos durante los cuales una clave de firma HMAC es válida antes de rotar a la siguiente. Este parámetro está diseñado principalmente para facilitar las pruebas de autenticación.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

ldapConnectionPoolHostRefreshIntervalMillis

Disponible solo para mongod.

Por defecto: 60000

El número de milisegundos entre las verificaciones de estado de las conexiones LDAP agrupadas.

Solo puede configurar ldapConnectionPoolHostRefreshIntervalMillis durante el inicio y no puede cambiar esta configuración con el comando de base de datos setParameter.

ldapConnectionPoolIdleHostTimeoutSecs

Disponible solo para mongod.

Por defecto: 300

El número máximo de segundos que las conexiones agrupadas a un servidor LDAP pueden permanecer inactivas antes de cerrarse.

Solo puede configurar ldapConnectionPoolIdleHostTimeoutSecs durante el inicio y no puede cambiar esta configuración con el comando de base de datos setParameter.

ldapConnectionPoolMaximumConnectionsInProgressPerHost

Disponible solo para mongod.

Modificado a partir de las versiones de MongoDB 5.0.9 y 6.0.0 Se cambió el valor por defecto a 2. En versiones anteriores, el valor por defecto no estaba establecido.

Por defecto: 2

El número máximo de operaciones de conexión en progreso para cada servidor LDAP.

Solo puede configurar ldapConnectionPoolMaximumConnectionsInProgressPerHost durante el inicio y no puede cambiar esta configuración con el comando de base de datos setParameter.

ldapConnectionPoolMaximumConnectionsPerHost

Disponible solo para mongod.

Modificado a partir de las versiones de MongoDB 5.0.9 y 6.0.0 Se cambió el valor por defecto a 2147483647. En versiones anteriores, el valor por defecto no estaba establecido.

Por defecto: 2147483647

La cantidad máxima de conexiones que se deben mantener abiertas para cada servidor LDAP.

Solo puede configurar ldapConnectionPoolMaximumConnectionsPerHost durante el inicio, y no puede cambiar esta configuración durante el tiempo de ejecución con el comando de base de datos setParameter.

ldapConnectionPoolMinimumConnectionsPerHost

Disponible solo para mongod.

Por defecto: 1

El número mínimo de conexiones que se deben mantener abiertas a cada servidor LDAP.

Solo puede configurar ldapConnectionPoolMinimumConnectionsPerHost durante el inicio, y no puede cambiar esta configuración durante el tiempo de ejecución con el comando de base de datos setParameter.

ldapConnectionPoolUseLatencyForHostPriority

Disponible solo para mongod.

Por defecto: true

Un booleano que determina si el pool de conexiones LDAP (véase ldapUseConnectionPool) debe usar la latencia de los servidores LDAP para determinar el orden de conexión (de menor a mayor latencia a mayor).

Solo puede configurar ldapConnectionPoolUseLatencyForHostPriority durante el inicio, y no puede cambiar esta configuración durante el tiempo de ejecución con el comando de base de datos setParameter.

ldapForceMultiThreadMode

Disponible tanto para mongod como para mongos.

Por defecto: false

Permite la ejecución de operaciones LDAP concurrentes.

Nota

Solo si se tiene la seguridad de que la instancia de libldap es segura para usar en este modo, se debe activar esta opción. Se pueden experimentar fallas del proceso de MongoDB si la versión libldap que se está utilizando no es segura para subprocesos.

Debes usar ldapForceMultiThreadMode para utilizar el pool de conexiones LDAP. Para habilitar el pool de conexiones LDAP, establece ldapForceMultiThreadMode y ldapUseConnectionPool a true.

Tip

Si se tiene alguna preocupación respecto a la versión de MongoDB, la versión del sistema operativo o la versión de libldap, se debe contactar a soporte de MongoDB.

ldapQueryPassword

Disponible solo para mongod.

Tipo: string

La contraseña que se utiliza para conectarse a un servidor LDAP. Debe usar ldapQueryUser con este parámetro.

Si no se establece, mongod o mongos no intentarán vincularse al servidor LDAP.

ldapQueryUser

Disponible solo para mongod.

Tipo: string

El usuario que se conecta a un servidor LDAP. Debe usar ldapQueryPassword con este parámetro.

Si no se establece, mongod o mongos no intentarán vincularse al servidor LDAP.

ldapRetryCount

Nuevo en la versión 6.1.

Disponible solo para mongod.

Tipo: entero

Por defecto: 0

Para implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas.

Cantidad de reintentos de operación por el administrador del servidor LDAP después de un error de red.

Por ejemplo, lo siguiente establece ldapRetryCount a 3 segundos:

mongod --ldapRetryCount=3

O, si utiliza el comando setParameter dentro de mongosh:

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

ldapShouldRefreshUserCacheEntries

Nuevo en la versión 5.2.

Disponible solo para mongod.

Tipo: booleano

Por defecto: true

Para implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas.

A partir de MongoDB 5.2, el intervalo de actualización para la información de usuario almacenada en caché recuperada de un servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Si es verdadero, utilice ldapUserCacheRefreshInterval.

• Si es falso, utiliza ldapUserCacheInvalidationInterval.

Solo puede configurar ldapShouldRefreshUserCacheEntries durante el inicio en el configuration file o con la opción --setParameter en la línea de comandos. Por ejemplo, lo siguiente desactiva ldapShouldRefreshUserCacheEntries:

mongod --setParameter ldapShouldRefreshUserCacheEntries=false

ldapUseConnectionPool

Disponible tanto para mongod como para mongos.

Especifica si MongoDB debe utilizar el agrupamiento de conexiones al conectarse al servidor LDAP para la autenticación y autorización.

MongoDB utiliza los siguientes valores por defecto:

• true en Windows.

• verdadero en Linux, donde los binarios de MongoDB Enterprise están vinculados contra libldap_r.

• falso en Linux, donde los binarios de MongoDB Enterprise están vinculados contra libldap.

Solo puede configurar ldapUseConnectionPool durante el inicio y no puede cambiar esta configuración con el comando de base de datos setParameter.

ldapUserCacheInvalidationInterval

Cambiado en la versión 5.2.

Disponible solo para mongod.

Por defecto: 30 segundos

Nota

A partir de MongoDB 5.2, el intervalo de actualización para la información de usuario almacenada en caché recuperada de un servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Si es verdadero, utilice ldapUserCacheRefreshInterval.

• Si es falso, utiliza ldapUserCacheInvalidationInterval.

Para su uso con implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas.

El intervalo (en segundos) que la instancia mongod espera entre los vaciados de la caché de usuarios externos. Después de que MongoDB vacíe la caché externa de usuarios, MongoDB vuelve a adquirir los datos de autorización del servidor LDAP la siguiente vez que un usuario autorizado por LDAP realice una operación.

Aumentar el valor especificado incrementa el tiempo que MongoDB y el servidor LDAP pueden estar sin sincronizar, pero reduce la carga en el servidor LDAP. Por el contrario, disminuir el valor especificado reduce el tiempo que MongoDB y el servidor LDAP pueden estar sin sincronizar, mientras que aumenta la carga en el servidor LDAP.

ldapUserCacheRefreshInterval

Nuevo en la versión 5.2.

Disponible solo para mongod.

Tipo: entero

Por defecto: 30 segundos

Nota

A partir de MongoDB 5.2, el intervalo de actualización para la información de usuario almacenada en caché recuperada de un servidor LDAP depende de ldapShouldRefreshUserCacheEntries:

• Si es verdadero, utilice ldapUserCacheRefreshInterval.

• Si es falso, utiliza ldapUserCacheInvalidationInterval.

Para implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas.

El intervalo en segundos que mongod espera antes de actualizar la información de usuario almacenada en caché desde el servidor LDAP.

El intervalo máximo es de 86 400 segundos (24 horas).

Por ejemplo, lo siguiente establece ldapUserCacheRefreshInterval a 4000 segundos:

mongod --setParameter ldapUserCacheRefreshInterval=4000

O, si utiliza el comando setParameter dentro de mongosh:

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

ldapUserCacheStalenessInterval

Nuevo en la versión 5.2.

Disponible solo para mongod.

Tipo: entero

Por defecto: 90 segundos

Para implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas.

El intervalo en segundos que mongod retiene la información de usuario LDAP almacenada en caché después de la última actualización de caché.

Si transcurren más de ldapUserCacheStalenessInterval segundos sin que se actualice con éxito la información del usuario desde el servidor LDAP, entonces mongod:

• Invalida la información de usuario de LDAP almacenada en caché.

• No puede autenticar nuevas sesiones para usuarios LDAP hasta que mongod se conecte al servidor LDAP y autorice al usuario LDAP.

• Autoriza cualquier sesión existente que utilice usuarios LDAP previamente autenticados si mongod no puede conectarse al servidor LDAP. Cuando mongod se reconecta al servidor LDAP, mongod garantiza que los usuarios de LDAP estén correctamente autorizados.

El intervalo máximo es de 86 400 segundos (24 horas).

Por ejemplo, lo siguiente establece ldapUserCacheStalenessInterval a 4000 segundos:

mongod --setParameter ldapUserCacheStalenessInterval=4000

O, si utiliza el comando setParameter dentro de mongosh:

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

maxValidateMemoryUsageMB

Disponible solo para mongod.

Nuevo en la versión 5.0.

Por defecto: 200

El límite máximo de uso de memoria en megabytes para el comando validate. Si se supera el límite, validate devuelve tantos resultados como sea posible y advierte que no se puede informar de toda la corrupción debido al límite.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

ocspEnabled

Disponible tanto para mongod como para mongos.

Disponible en Linux y macOS.

Por defecto: true

El indicador que habilita o deshabilita OCSP.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, lo siguiente desactiva OCSP:

mongod --setParameter ocspEnabled=false ...

Al iniciar MongoDB 6.0, si ocspEnabled se configura como true durante la sincronización inicial, todos los nodos deben poder acceder al respondedor OCSP.

Si un nodo falla en el estado STARTUP2, establezca tlsOCSPVerifyTimeoutSecs a un valor que sea inferior a 5.

Tip

• ocspStaplingRefreshPeriodSecs

• tlsOCSPStaplingTimeoutSecs

• tlsOCSPVerifyTimeoutSecs

ocspStaplingRefreshPeriodSecs

Disponible tanto para mongod como para mongos.

Disponible en Linux.

El número de segundos que se debe esperar antes de actualizar la respuesta de estado OCSP grapado. Especifique un número mayor o igual a 1.

Solo puede establecer ocspStaplingRefreshPeriodSecs durante el inicio en el configuration file o con la opción --setParameter en la línea de comandos. Por ejemplo, lo siguiente establece el parámetro en 3600 segundos:

mongod --setParameter ocspStaplingRefreshPeriodSecs=3600 ...

A partir de MongoDB 5.0, el comando rotateCertificates y el método db.rotateCertificates() también actualizarán cualquier respuesta OCSP adjunta.

Tip

• ocspEnabled

• tlsOCSPStaplingTimeoutSecs

• tlsOCSPVerifyTimeoutSecs

oidcIdentityProviders

Disponible solo para mongod.

Cambiado en la versión 8.0: (También disponible en 7.3 y 7.0)

Utiliza este parámetro para especificar las configuraciones del proveedor de identidad (IDP) al utilizar la autenticación de OpenID Connect.

oidcIdentityProviders acepta un arreglo de cero o más configuraciones de proveedor de identidad (proveedor de identidad). Un arreglo vacío (por defecto) indica que no se hay soporte para OpenID Connect.

Cuando se define más de un proveedor de identidad, oidcIdentityProviders utiliza el campo matchPattern para seleccionar un proveedor de identidad. El orden del arreglo determina la prioridad y siempre se selecciona el primer proveedor de identidad.

A partir de MongoDB 8.0, cuando se definen varios proveedores de identidad (IDP), el parámetro oidcIdentityProviders acepta valores issuer duplicados siempre que el valor audience sea único para cada emisor. También está disponible en las versiones 7.3 y 7.0.

Campos de oidcIdentityProviders

Campo	Necesidad	Tipo	Descripción
issuer	Requerido	string	El URI del emisor del proveedor de identidad del que el servidor debería aceptar tokens. Esto debe coincidir con el campo iss en cualquier JWT utilizado para la autenticación. A partir de MongoDB 8.0, cuando se definen varios proveedores de identidad (IDP), el parámetro oidcIdentityProviders acepta valores issuer duplicados siempre que el valor audience sea único para cada emisor. También está disponible en las versiones 7.3 y 7.0. Si especifica un URI de emisor inalcanzable, MongoDB: Registra una advertencia. Se debe continuar el inicio del servidor, lo que permite actualizar el URI del emisor. Reintenta el contacto con el emisor. Si MongoDB alcanza el URI del emisor y valida el token de acceso, la autenticación se realiza con éxito. Si el URI del emisor sigue siendo inalcanzable, la autenticación fallará. Cambiado en la versión 8.0: (También disponible en 7.3 y 7.0)
authNamePrefix	Requerido	string	Prefijo único aplicado a cada UserName generado y RoleName utilizado en la autorización. authNamePrefix solo puede contener los siguientes caracteres: caracteres alfanuméricos (combinación de a a z y de 0 a 9) guiones (-) guiones bajos (_)
matchPattern	Condicional	string	Patrón de expresiones regulares utilizado para determinar qué proveedor de identidad se debe utilizar. matchPattern coincide con los nombres de usuario. El orden del arreglo determina la prioridad, y siempre se selecciona el primer proveedor de identidad. matchPattern es necesario en algunas configuraciones, dependiendo de cómo el usuario configure supportsHumanFlows: Cuando solo un proveedor de identidad tiene supportsHumanFlows configurado en true (el valor por defecto), matchPatterns es opcional. Cuando varios proveedores de identidad tienen supportsHumanFlows establecido en true (el valor por defecto), cada uno de estos requiere matchPatterns. matchPatterns es opcional para cualquier proveedor de identidad donde supportsHumanFlows esté configurado como false. Esto no es un mecanismo de seguridad. matchPattern sirve únicamente como asesor para los clientes. MongoDB acepta tokens emitidos por el proveedor de identidad cuyos nombres principales no coinciden con este patrón.
clientId	Condicional	string	ID proporcionado por el proveedor de identidad para identificar al cliente que recibe los tokens de acceso. Requerido cuando supportsHumanFlows se establece en true (por defecto).
audience	Requerido	string	Especifica la aplicación o el servicio para el cual está destinado el token de acceso. A partir de MongoDB 7.0, solo se puede especificar un campo audience oidcIdentityProviders para los tokens de acceso OIDC. Los campos audience con arreglos vacíos o arreglos de varios strings no son válidos. Cuando se define más de un proveedor de identidad, este debe ser un valor único para cada configuración que comparta un issuer.
requestScopes	Opcional	arreglo [ string ]	Permisos y niveles de acceso que MongoDB solicita al proveedor de identidad. IMPORTANTE: Por defecto, los clientes como Compass y mongosh solicitan los ámbitos oidc y offline_access al proveedor de identidad. Si el proveedor de identidad no admite oidc ni offline_access, el cliente no los solicita. Si el proveedor de identidad admite oidc pero no offline_access, deberá volver a autenticarse con frecuencia.
principalName	Opcional	string	La reclamación que debe extraerse del token de acceso que contiene los identificadores de usuario de MongoDB. El valor por defecto es sub (representa subject).
useAuthorizationClaim	Opcional	booleano	Determina si se requiere el authorizationClaim. El valor por defecto es true. Si el campo useAuthorizationClaim se establece en true, el servidor requiere un authorizationClaim para la configuración del proveedor de identidad. Este es el comportamiento por defecto. Si el campo useAuthorizationClaim se establece en false, el campo authorizationClaim es opcional (y se ignora si se proporciona). En su lugar, el servidor realiza lo siguiente: Busca en el token una reclamación cuyo nombre esté listado en el campo principalNameClaim Esto normalmente se llama sub. Por ejemplo: sub: "spencer.jackson@example.com" Construye el nombre de usuario interno concatenando el authNamePrefix, una barra diagonal (/), y el contenido de la reclamación identificada por principalNameClaim dentro del token de acceso. Por ejemplo, con un valor de campo authNamePrefix de "mdbinc", el nombre de usuario interno es: mdbinc/spencer.jackson@example.com Busca al usuario con este nombre de usuario y autoriza al cliente con los roles: { user: "mdbinc/spencer.jackson@example.com", db: "$external" } Nuevo en la versión 7.2: (También disponible en la versión 7.0.5)
authorizationClaim	Condicional	string	Obligatorio, a menos que useAuthorizationClaim esté configurado en false. Reclamo extraído del token de acceso que contiene nombres de roles de MongoDB.
logClaims	Opcional	arreglo [ string ]	Lista de declaraciones de tokens de acceso para incluir en los mensajes de registro y para auditar al completar la autenticación.
JWKSPollSecs	Opcional	entero	Frecuencia, en segundos, para solicitar un conjunto actualizado de claves web JSON (JWKS) al proveedor de identidad. Con una configuración de 0, se desactiva el sondeo. Cuando se define más de un proveedor de identidad, este debe tener el mismo valor para cada configuración que comparta un issuer.
supportsHumanFlows	Opcional	bool	Ya sea que el proveedor de OIDC dé soporte a flujos de trabajo humanos o de máquina. Esto afecta a los campos clientId y matchPattern. Puede resultarle útil establecer este campo en false con los proveedores de identidad de carga de trabajo de las máquinas para permitirles omitir el clientId cuando no sea necesario. Por defecto: true. Nuevo en la versión 7.2.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

opensslCipherConfig

Disponible tanto para mongod como para mongos.

Disponible solamente en Linux.

Con el uso de librerías TLS/SSL nativas, el parámetro opensslCipherConfig es compatible con Linux/BSD y ya no es compatible con Windows y macOS.

Especifique el string de cifrado para OpenSSL cuando utilice el cifrado TLS/SSL. Para obtener una lista de cadenas de cifrado, consulte https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Se pueden proporcionar múltiples cadenas de cifrado como una lista separada por dos puntos.

Nota

Este parámetro es solo para uso con TLS 1.2 o versiones anteriores. Para especificar suites de cifrado para usar con TLS 1.3, utilice el parámetro opensslCipherSuiteConfig.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Se prefiere el uso de las opciones de TLS sobre las opciones de SSL. Las opciones de TLS tienen la misma funcionalidad que las opciones SSL. El siguiente ejemplo configura un mongod con una string de cifrado opensslCipherConfig de 'HIGH:!EXPORT:!aNULL@STRENGTH':

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

opensslCipherSuiteConfig

Disponible tanto para mongod como para mongos.

Nuevo en la versión 5.0.

Disponible solamente en Linux.

Especifica la lista de suites de cifrado compatibles que OpenSSL debe permitir al utilizar el cifrado TLS 1.3.

Para obtener una lista de los conjuntos de cifrado para usar con TLS 1.3, consulte https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html. Se pueden proporcionar múltiples suites de cifrado como una lista separada por dos puntos.

Nota

Este parámetro es solo para uso con TLS 1.3. Para especificar cadenas de cifrado para usar con TLS 1.2 o anterior, utilice el parámetro opensslCipherConfig.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, la siguiente configuración de un mongod con un conjunto de cifrado opensslCipherSuiteConfig de 'TLS_AES_256_GCM_SHA384' para usar con TLS 1.3:

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

opensslDiffieHellmanParameters

Disponible tanto para mongod como para mongos.

Disponible solamente en Linux.

Especifique la ruta al archivo PEM que contiene los parámetros de OpenSSL Diffie-Hellman cuando se utiliza TLS 1.2 o versiones anteriores. Especificar los parámetros de OpenSSL Diffie-Hellman permite el soporte para los conjuntos de cifrado Ephemeral Diffie-Hellman (DHE) durante el cifrado TLS/SSL.

Este parámetro no es compatible para su uso con TLS 1.3.

Los conjuntos de cifrado Ephemeral Diffie-Hellman (DHE) y los conjuntos de cifrado Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)) proporcionan el secreto perfecto hacia adelante. Las suites de cifrado secreto perfecto hacia adelante crean una clave de sesión efímera que está protegida por la llave privada del servidor, pero que nunca se transmite. Esto asegura que, incluso si la llave privada de un servidor se ve comprometida, no podrás descifrar sesiones pasadas con la llave comprometida.

Nota

Si opensslDiffieHellmanParameters no está configurado, pero ECDHE está habilitado, MongoDB activa DHE mediante el parámetro Diffie-Hellman ffdhe3072, como se define en RFC-7919#appendix-A.2. El ffdhe3072 es un parámetro fuerte (específicamente, el tamaño es mayor que 1024). Los parámetros fuertes no son compatibles con Java 6 y 7 a menos que se haya adquirido soporte extendido de Oracle.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Si por razones de rendimiento necesita deshabilitar el soporte para los conjuntos de cifrado DHE, utilice el parámetro opensslCipherConfig:

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

pessimisticConnectivityCheckForAcceptedConnections

Disponible solamente en Linux.

Tipo: booleano

Por defecto: false

Cuando se establece en true, indica al servidor que verifique la conectividad de las conexiones aceptadas antes de procesarlas y descarte inmediatamente las conexiones que el cliente finaliza.

Considere activar este parámetro en tipos de instancias más pequeños. Puede utilizarlo cuando desee intercambiar una pequeña cantidad de latencia en el establecimiento de nuevas conexiones por una reducción del trabajo del servidor en el procesamiento de nuevas conexiones que ya se han cerrado en el lado del cliente.

saslauthdPath

Disponible tanto para mongod como para mongos.

Nota

Disponible solo en MongoDB Enterprise (excepto MongoDB Enterprise para Windows).

Especifique la ruta al socket de dominio Unix de la instancia saslauthd que se usará para la autenticación de proxy.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

saslHostName

Disponible tanto para mongod como para mongos.

saslHostName anula la detección por defecto de nombres de host de MongoDB para la configuración de la autenticación SASL y Kerberos.

saslHostName no afecta el nombre de host de la instancia de mongod o mongos para ningún propósito más allá de la configuración de SASL y Kerberos.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Nota

saslHostName admite la autenticación Kerberos y solo se incluye en MongoDB Enterprise. Para obtener más información, consulta lo siguiente:

• Linux: Configurar MongoDB autogestionado con autenticación Kerberos en Linux

• Windows: Configurar MongoDB autogestionado con autenticación Kerberos en Windows

saslServiceName

Disponible tanto para mongod como para mongos.

Permite a los usuarios sobrescribir el componente por defecto del nombre de servicio Kerberos del nombre principal de Kerberos, en cada instancia. Si no se especifica, el valor es por defecto es mongodb.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

saslServiceName solo está disponible en MongoDB Enterprise.

Importante

Asegúrese de que su controlador tenga soporte para nombres de servicios alternativos.

scramIterationCount

Disponible tanto para mongod como para mongos.

Por defecto: 10000

Cambia el número de iteraciones de hash utilizadas para todas las nuevas contraseñas de SCRAM-SHA-1. Más iteraciones aumentan el tiempo necesario para que los clientes se autentiquen en MongoDB, pero hacen que las contraseñas sean menos vulnerables a los intentos de fuerza bruta. El valor por defecto es ideal para la mayoría de los casos de uso y requisitos comunes.

Si modifica este valor, no cambiará el número de iteraciones de las contraseñas existentes. El valor de scramIterationCount debe ser 5000 o mayor.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, lo siguiente configura el scramIterationCount a 12000.

mongod --setParameter scramIterationCount=12000

O, si utiliza el comando setParameter dentro de mongosh:

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

Tip

• db.changeUserPassword()

• db.createUser()

• db.updateUser()

scramSHA256IterationCount

Disponible tanto para mongod como para mongos.

Por defecto: 15000

Cambia el número de iteraciones de hash utilizadas para todas las nuevas contraseñas de SCRAM-SHA-256. Más iteraciones aumentan el tiempo necesario para que los clientes se autentiquen en MongoDB, pero hacen que las contraseñas sean menos vulnerables a los intentos de fuerza bruta. El valor por defecto es ideal para la mayoría de los casos de uso y requisitos comunes.

Si modifica este valor, no cambiará el número de iteraciones de las contraseñas existentes. El valor de scramSHA256IterationCount debe ser 5000 o mayor.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, lo siguiente configura el scramSHA256IterationCount a 20000.

mongod --setParameter scramSHA256IterationCount=20000

O, si utiliza el comando setParameter dentro de mongosh:

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

Tip

• db.changeUserPassword()

• db.createUser()

• db.updateUser()

sslMode

Disponible tanto para mongod como para mongos.

Establece el net.ssl.mode en preferSSL o requireSSL. Útil durante la actualización progresiva a TLS/SSL para minimizar el tiempo de inactividad.

Para obtener más información sobre TLS/SSL y MongoDB, consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autogestionadas y Configuración de TLS/SSL para clientes .

Este parámetro solo está disponible en tiempo de ejecución. Para establecer el parámetro, utilice el comando setParameter.

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

Tip

tlsMode

tlsClusterAuthX509Override

Disponible tanto para mongod como para mongos.

Nuevo en la versión 7.0.

Anula las opciones de configuraciónclusterAuthX509.

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

El parámetro ofrece soporte para anulaciones de attributes y extensionValue.

Cuando el servidor autentica las conexiones de los nodos, analiza el certificado X.509 para determinar si pertenece a un nodo del clúster. Si el servidor utiliza la configuración attributes o el campo attributes en el parámetro tlsClusterAuthX509Override, verifica los valores del nombre distinguido (DN) del certificado. Si se establece la configuración extensionValue o el campo extensionValue del parámetro tlsClusterAuthX509Override, se verifican los valores de extensión del certificado. Si encuentra una coincidencia, autoriza la conexión como un emparejamiento.

Utiliza este parámetro para rotar los certificados cuando los nuevos certificados tengan atributos o valores de extensión diferentes.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

tlsMode

Disponible tanto para mongod como para mongos.

Establezca en uno de los siguientes:

• preferTLS

• requireTLS

El parámetro tlsMode es útil durante la actualización progresiva a TLS/SSL para minimizar el tiempo de inactividad.

Este parámetro solo está disponible en tiempo de ejecución. Para establecer el parámetro, utilice el comando setParameter.

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

Para obtener más información sobre TLS/SSL y MongoDB, consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autogestionadas y Configuración de TLS/SSL para clientes .

Tip

sslMode

tlsOCSPStaplingTimeoutSecs

Disponible tanto para mongod como para mongos.

Disponible para Linux.

El número máximo de segundos que la instancia mongod / mongos debe esperar para recibir la respuesta de estado OCSP para sus certificados.

Especifique un número entero mayor o igual a (>=) 1. Si no se establece, tlsOCSPStaplingTimeoutSecs utiliza el valor de tlsOCSPVerifyTimeoutSecs.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, lo siguiente establece el tlsOCSPStaplingTimeoutSecs a 20 segundos:

mongod --setParameter tlsOCSPStaplingTimeoutSecs=20 ...

Tip

• ocspEnabled

• ocspStaplingRefreshPeriodSecs

• tlsOCSPVerifyTimeoutSecs

tlsOCSPVerifyTimeoutSecs

Disponible tanto para mongod como para mongos.

Disponible para Linux y Windows.

Por defecto: 5

El número máximo de segundos que mongod / mongos debería esperar la respuesta de OCSP al verificar los certificados del servidor.

Especifique un número entero mayor o igual a (>=) 1.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, lo siguiente establece el tlsOCSPVerifyTimeoutSecs a 20 segundos:

mongod --setParameter tlsOCSPVerifyTimeoutSecs=20 ...

Tip

• ocspEnabled

• ocspStaplingRefreshPeriodSecs

• tlsOCSPStaplingTimeoutSecs

tlsUseSystemCA

Disponible solo para mongod.

Tipo: booleano

Por defecto: false

Especifica si MongoDB carga los certificados TLS que ya están disponibles para la autoridad de certificación del sistema operativo.

Importante

Al iniciar una instancia mongod con TLS/SSL habilitado, debes especificar un valor para el indicador --tlsCAFile, la opción de configuración net.tls.CAFile o el parámetro tlsUseSystemCA.

--tlsCAFile, tls.CAFile, y tlsUseSystemCA son mutuamente excluyentes.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para configurar tlsUseSystemCA a true:

mongod --setParameter tlsUseSystemCA=true

Para obtener más información sobre TLS/SSL y MongoDB, consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autogestionadas y Configuración de TLS/SSL para clientes .

tlsWithholdClientCertificate

Disponible tanto para mongod como para mongos.

Por defecto: false

Se establece un certificado TLS para un mongod o un mongos ya sea mediante la opción --tlsClusterFile o la opción --tlsCertificateKeyFile cuando --tlsClusterFile no está configurado. Si se establece el certificado TLS, por defecto, la instancia envía el certificado al iniciar comunicaciones intraclúster con otras instancias mongod o mongos en la implementación. Configura tlsWithholdClientCertificate en 1 o true para dirigir a la instancia a que retenga el envío de su certificado TLS durante estas comunicaciones. Utiliza esta opción con --tlsAllowConnectionsWithoutCertificates (para permitir conexiones entrantes sin certificados) en todos los nodos de la implementación. tlsWithholdClientCertificate es mutuamente excluyente con --clusterAuthMode x509.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

tlsX509ClusterAuthDNOverride

Disponible tanto para mongod como para mongos.

Un nombre distinguido alternativo (nombre distinguido) que la instancia también puede utilizar para identificar a los nodos de la implementación.

Para una implementación de MongoDB que utiliza certificados X.509 para clusterAuthMode, los nodos de la implementación se identifican entre sí mediante certificados X.509 ( net.tls.clusterFile, si se especifica, y net.tls.certificateKeyFile) durante las comunicaciones intraclúster. Para los nodos de la misma implementación, el DN de sus certificados debe tener los mismos atributos de la organización (O), los atributos de la unidad organizacional (OU) y los componentes de dominio (DC).

Si tlsX509ClusterAuthDNOverride se establece para un miembro, este también puede utilizar el valor de anulación al comparar los componentes DN (O, OU, y DC) de los certificados presentados. Es decir, el miembro verifica los certificados presentados en comparación con su net.tls.clusterFile/net.tls.certificateKeyFile. Si el nombre distinguido no coincide, el miembro verifica el certificado presentado comparado con el valor de tlsX509ClusterAuthDNOverride.

Nota

Si se establece, debe configurar este parámetro en todos los nodos de la implementación.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Puedes utilizar este parámetro para actualizar de forma continua los certificados a nuevos certificados que contengan un nuevo valor DN. Consulta Rotar certificados en clústeres autogestionados sin clusterAuthX509.

Para obtener más información sobre los requisitos del certificado de membresía, consulte Requisitos del Certificado de membresía para obtener más detalles.

tlsX509ExpirationWarningThresholdDays

Disponible tanto para mongod como para mongos.

Por defecto: 30

mongod / mongos registra una advertencia en la conexión si el certificado X.509 presentado caduca dentro de los 30 días del reloj del sistema mongod/mongos. Utilice el parámetro tlsX509ExpirationWarningThresholdDays para controlar el umbral de advertencia de caducidad del certificado:

• Aumenta el valor del parámetro para activar advertencias con mayor antelación a la fecha de vencimiento del certificado.

• Disminuya el valor del parámetro para activar advertencias más cercanas a la fecha de caducidad del certificado.

• Establezca el parámetro en 0 para desactivar la advertencia.

Este parámetro tiene un valor mínimo de 0.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Para obtener más información sobre la validez del certificado X.509, consulte RFC 5280 4.1.2.5.

userCacheInvalidationIntervalSecs

Disponible solo para mongos.

Por defecto: 30

En una instancia de mongos, se especifica el intervalo (en segundos) en el que la instancia de mongos verifica si la caché en memoria de objetos de usuario contiene datos obsoletos y, de ser así, limpia la caché. Si no hay cambios en los objetos de usuario, mongos no limpiará la caché.

Este parámetro tiene un valor mínimo de 1 segundo y un valor máximo de 86400 segundos (24 horas).

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Parámetros generales

allowDiskUseByDefault

Disponible solo para mongod.

Por defecto: true

A partir de MongoDB 6.0, las etapas de la canalización que requieren más de 100 megabytes de memoria para ejecutarse escriben archivos temporales en el disco de forma predeterminada. Estos archivos temporales duran mientras se ejecuta la canalización y pueden afectar el espacio de almacenamiento de la instancia. En versiones anteriores de MongoDB, se debía pasar { allowDiskUse: true } a los comandos find y aggregate para habilitar este comportamiento.

Los comandos individuales find y aggregate pueden anular el parámetro allowDiskUseByDefault de las siguientes maneras:

• Se utiliza { allowDiskUse: true } para permitir la escritura de archivos temporales en el disco cuando allowDiskUseByDefault se establece en false

• Se utiliza { allowDiskUse: false } para prohibir la escritura de archivos temporales en el disco cuando allowDiskUseByDefault esté configurado en true

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

mongod --setParameter allowDiskUseByDefault=false

allowDiskUseByDefault solo funciona en mongod y no en mongos. mongos nunca guarda archivos temporales en el disco. Utiliza el comando setParameter en una sesión mongosh que esté conectada a un mongod en ejecución para cambiar el valor del parámetro mientras el servidor está en funcionamiento:

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

connPoolMaxConnsPerHost

Disponible tanto para mongod como para mongos.

Por defecto: 200

Establece el tamaño máximo de los pools de conexiones heredados para las conexiones salientes a otras instancias de mongod en el pool de conexiones global. El tamaño de un pool no impide la creación de conexiones adicionales, pero sí impide que un pool de conexiones retenga conexiones en exceso del valor de connPoolMaxConnsPerHost.

Nota

El parámetro está separado de las conexiones en los pools de TaskExecutor. Consulte ShardingTaskExecutorPoolMaxSize.

Ajuste esta configuración solo si su controlador no agrupa conexiones y está utilizando autenticación en el contexto de un clúster particionado.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

mongod --setParameter connPoolMaxConnsPerHost=250

connPoolMaxInUseConnsPerHost

Disponible tanto para mongod como para mongos.

Establece el número máximo de conexiones en uso en un momento dado para las conexiones salientes a otras instancias de mongod en el pool de conexiones global heredado.

Por defecto, el parámetro no está establecido.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

mongod --setParameter connPoolMaxInUseConnsPerHost=100

Tip

connPoolMaxConnsPerHost

cursorTimeoutMillis

Disponible tanto para mongod como para mongos.

Por defecto: 600000 (10 minutos)

Establece el umbral de expiración en milisegundos para los cursores inactivos antes de que MongoDB los remueva; específicamente, MongoDB remueve los cursores que han estado inactivos durante el tiempo especificado de cursorTimeoutMillis.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, lo siguiente configura la cursorTimeoutMillis a 300000 milisegundos (5 minutos).

mongod --setParameter cursorTimeoutMillis=300000

O, si utiliza el comando setParameter dentro de mongosh:

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

Configurar cursorTimeoutMillis a un valor menor o igual que 0 hace que todos los cursores sean inmediatamente elegibles para el tiempo de espera. Por lo general, el valor del tiempo de espera debe ser superior al tiempo promedio que tarda una query en devolver resultados. Utilice herramientas como el modificador de cursor cursor.explain() para analizar el tiempo promedio de la query y seleccione un período de espera adecuado.

Advertencia

MongoDB elimina los cursores huérfanos después del umbral cursorTimeoutMillis solo si no están asociados a sesiones.

MongoDB limpia los cursores vinculados a sesiones con el ciclo de vida localLogicalSessionTimeoutMinutes, independientemente del valor de cursorTimeoutMillis. Para gestionar largos periodos de inactividad, utilice Mongo.startSession() y actualice la sesión mediante el comando refreshSessions. Para obtener más detalles, consulte Actualizar un cursor con refreshSessions.

fassertOnLockTimeoutForStepUpDown

Novedades en la versión 5.3.

Disponible tanto para mongod como para mongos.

Por defecto: 15 segundos

Permite que un servidor que recibe una solicitud para aumentar o disminuir su capacidad termine si no puede cumplir (por ejemplo, debido a discos defectuosos del servidor) dentro del tiempo de espera. Esto permite a un clúster elegir con éxito un nuevo nodo primario y, por lo tanto, seguir estando disponible.

fassertOnLockTimeoutForStepUpDown El valor por defecto es de 15 segundos. Para deshabilitar que los nodos realicen fasserting, establece fassertOnLockTimeoutForStepUpDown=0.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo deshabilita los nodos de fasserting:

mongod --setParameter fassertOnLockTimeoutForStepUpDown=0

globalConnPoolIdleTimeoutMinutes

Disponible tanto para mongod como para mongos.

Establece el límite de tiempo que una conexión en el pool de conexiones global heredado puede permanecer inactiva antes de cerrarse.

Por defecto, el parámetro no está establecido.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

mongos --setParameter globalConnPoolIdleTimeoutMinutes=10

httpVerboseLogging

Disponible tanto para mongod como para mongos.

Agrega un seguimiento más detallado para curl en Linux y macOS. No afecta a Windows.

Por defecto, el parámetro no está establecido.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

mongos --setParameter httpVerboseLogging=true

indexBuildMinAvailableDiskSpaceMB

Nuevo en la versión 7.1.

Disponible solo para mongod.

Default: 500 MB

Establece el espacio mínimo disponible en disco, en megabytes, que se requiere para la creación de índices.

Debe ser mayor o igual a 0 MB y menor o igual a 8 TB. 0 desactiva el requisito mínimo de espacio en disco.

No se puede iniciar una nueva creación de índices y se cancela una creación de índices actual si el espacio disponible en disco es inferior a indexBuildMinAvailableDiskSpaceMB.

Advertencia

Si se aumenta indexBuildMinAvailableDiskSpaceMB, es necesario garantizar que el servidor tenga suficiente espacio disponible en el disco. Además, si se establece indexBuildMinAvailableDiskSpaceMB demasiado alto, se podría impedir innecesariamente la creación de índices cuando haya suficiente espacio en disco y indexBuildMinAvailableDiskSpaceMB se podría establecer más bajo.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo configura indexBuildMinAvailableDiskSpaceMB a 650 MB:

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

También puedes configurar indexBuildMinAvailableDiskSpaceMB al inicio. Por ejemplo:

mongod --setParameter indexBuildMinAvailableDiskSpaceMB=650

indexMaxNumGeneratedKeysPerDocument

Disponible tanto para mongod como para mongos.

Novedades en la versión 5.3.

Por defecto: 100000

Limita el número máximo de claves generadas para un documento para evitar errores de falta de memoria. Es posible aumentar el límite, pero si una operación requiere más claves de las que especifica el parámetro indexMaxNumGeneratedKeysPerDocument, la operación fallará.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

ingressAdmissionControllerTicketPoolSize

Disponible solo para mongod.

Por defecto: 1000000

Controla el número máximo de operaciones admitidas simultáneamente en la cola de ingreso. El valor por defecto de 1000000 representa el equivalente numérico del ajuste ilimitado, que admite todas las operaciones entrantes hasta el máximo de conexiones por defecto que permite MongoDB.

Aumentar este valor mientras haya operaciones esperando en la cola desbloquea tantas operaciones como lo permita el nuevo tamaño del pool. Reducir este valor no bloquea ninguna operación que se esté ejecutando actualmente, pero las operaciones controlables entrantes se bloquean hasta que haya tickets disponibles.

mongod --setParameter ingressAdmissionControllerTicketPoolSize=100000

Advertencia

Evite modificar ingressAdmissionControllerTicketPoolSize a menos que lo indiquen los ingenieros de MongoDB. Esta configuración tiene importantes implicaciones tanto en WiredTiger como en MongoDB.

ingressConnectionEstablishmentRateLimiterEnabled

Nuevo en la versión 8.2: (también disponible en 8.1.1 y 8.0.12)

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: false

Determina si está activado el límite de tasa para el establecimiento de nuevas conexiones. Cuando se activa, MongoDB aplica la limitación de tasa para controlar el número de nuevas conexiones que se pueden establecer por segundo.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

ingressConnectionEstablishmentRatePerSec

Nuevo en la versión 8.2: (también disponible en 8.1.1 y 8.0.12)

Disponible tanto para mongod como para mongos.

Tipo: int32

Por defecto: desactivado

Mínimo: 1

Especifica el número máximo de conexiones nuevas que se pueden establecer por segundo cuando se activa el límite de tasa.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

ingressConnectionEstablishmentBurstCapacitySecs

Nuevo en la versión 8.2: (también disponible en 8.1.1 y 8.0.12)

Disponible tanto para mongod como para mongos.

Tipo: doble

Por defecto: desactivado

Mínimo: 1

Describe cuántos segundos de establecimientos de conexión puede admitir el servidor antes de que comience la limitación de tasa. Esto permite al servidor gestionar ráfagas temporales de solicitudes de conexión que exceden el límite de tasa especificado por ingressConnectionEstablishmentRatePerSec.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

ingressConnectionEstablishmentMaxQueueDepth

Nuevo en la versión 8.2: (también disponible en 8.1.1 y 8.0.12)

Disponible tanto para mongod como para mongos.

Tipo: int32

Por defecto: 0 (desactivado)

Especifica el número máximo de intentos de conexión en la cola de establecimiento de conexión. Una vez que la cola alcanza este número de intentos de conexión, el servidor rechaza nuevos intentos de conexión.

El valor por defecto de 0 significa que el servidor rechaza todas las conexiones que se pondrán en cola para establecerse.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

ingressConnectionEstablishmentRateLimiterBypass

Nuevo en la versión 8.2: (también disponible en 8.1.1 y 8.0.12)

Disponible tanto para mongod como para mongos.

Tipo: arreglo de strings

Por defecto: []

Proporciona una lista de direcciones IP y rangos CIDR que el servidor debe eximir de los límites de la tasa de establecimiento de conexión. Esto permite a clientes de confianza específicos eludir las restricciones de limitación de velocidad.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

maxIndexBuildMemoryUsageMegabytes

Disponible solo para mongod.

Default (absolute): 200

Minimum (absolute): 50

Maximum (percent): 0.8

Limita la cantidad de memoria que las compilaciones simultáneas de índices en una colección pueden consumir. La cantidad de memoria especificada se comparte entre todos los índices compilados con un solo comandocreateIndexeso su asistente de shelldb.collection.createIndexes(). Aumentar el límite puede evitar impactos negativos en el rendimiento en algunos casos, como al compilar varios índices simultáneamente con un solo comandocreateIndexeso al trabajar con conjuntos de datos de claves de índice que superan los 500GB. La memoria consumida por la compilación de un índice es independiente de la memoria caché de WiredTiger (véasecacheSizeGB).

• Establezca este valor en 0-0.8 para limitar las compilaciones a un porcentaje de memoria.

• Establezca este valor en 1.0 o superior para limitar las compilaciones a un número absoluto de megabytes.

Si esta configuración asigna menos de 50 MB, mongod utiliza un mínimo de 50 MB. Si la configuración del porcentaje es superior a 0.8, mongod utiliza un máximo del 80 % de la memoria disponible.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

maxNumActiveUserIndexBuilds

Disponible solo para mongod.

Tipo: entero

Por defecto: 3

Establece el número máximo de solicitudes de creación de índices que MongoDB puede realizar de manera concurrente. maxNumActiveUserIndexBuilds es un límite global que se aplica a todas las colecciones.

La siguiente tabla muestra los valores predeterminados para maxNumActiveUserIndexBuilds según los niveles de Atlas:

Atlas Tiers	maxNumActiveUserIndexBuilds Predeterminado
Niveles M pequeños (M10, M20, M30, M40)	1
Niveles M medianos (M50, M60)	2
Niveles M grandes (M80 y superiores, incluidas las variantes NMVe)	3

Nota

Estos valores predeterminados también se aplican a los niveles de CPU baja R correspondientes.

El comando createIndexes crea índices. Incluso si el comando createIndexes compila varios índices a la vez, la ejecución del comando solo agrega 1 a maxNumActiveUserIndexBuilds.

Incrementar el valor de maxNumActiveUserIndexBuilds permite la creación de índices concurrentes adicionales con el costo de una mayor presión sobre la caché de WiredTiger.

Los índices del sistema no están limitados a maxNumActiveUserIndexBuilds; sin embargo, la creación de un índice del sistema cuenta para el límite de creaciones de índices de usuario.

Después de que el servidor alcanza maxNumActiveUserIndexBuilds, bloquea la creación de índices de usuario adicionales hasta que el número de creaciones de índices concurrentes desciende por debajo del límite de maxNumActiveUserIndexBuilds. Si una creación de índices está bloqueada, el servidor genera un registro con este mensaje:

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

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente comando establece un límite de 4 creaciones de índices concurrentes:

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

Véase también:

• maxIndexBuildMemoryUsageMegabytes

• Creación de índices en colecciones pobladas

notablescan

Disponible solo para mongod.

Impide la ejecución de algunos escaneos de colección cuando se podría utilizar un índice, esté presente o no. Si true, MongoDB no ejecutará queries que requieran un escaneo de colección y devolverá un error. Las exclusiones incluyen consultas sin filtros y consultas contra colecciones limitadas, como el oplog.

Considere el siguiente ejemplo que establece notablescan a true o verdadero:

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

Configurar notablescan a true puede ser útil para probar queries de aplicación, por ejemplo, para identificar queries que escanean toda una colección y no pueden usar un índice.

Para detectar queries no indexadas sin notablescan, puede leer la sección Analizar el rendimiento del query y usar el parámetro logLevel, mongostat y el perfilado.

No ejecute instancias de producción mongod con notablescan porque impedir los escaneos de colecciones puede afectar potencialmente a las queries en todas las bases de datos, incluidas las queries administrativas.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Nota

notablescan no permite queries ilimitadas que usan un índice agrupado porque las queries requieren un escaneo de colección completo. Para obtener más información, consulta Escaneos de colección.

reportOpWriteConcernCountersInServerStatus

Disponible solo para mongod.

Por defecto: false

Una bandera booleana que determina si el método db.serverStatus() y el comando serverStatus devuelven información opWriteConcernCounters. [1]

mongod --setParameter reportOpWriteConcernCountersInServerStatus=true

[1]	Habilitar reportOpWriteConcernCountersInServerStatus puede tener un impacto negativo en el rendimiento; específicamente, cuando se ejecuta sin TLS.

slowConnectionThresholdMillis

Nuevo en la versión 6.3.

Disponible tanto para mongod como para mongos.

Por defecto: 100

Establece el límite de tiempo en milisegundos para el registro del establecimiento de conexiones lentas con el servidor.

Si una conexión tarda más en establecerse que el parámetro slowConnectionThresholdMillis, se agrega un evento al registro con el campo de mensaje msg configurado en "Slow connection establishment".

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo configura slowConnectionThresholdMillis a 250 milisegundos.

mongod --setParameter slowConnectionThresholdMillis=250

O, si utiliza el comando setParameter dentro de mongosh:

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

tcmallocEnableBackgroundThread

Disponible tanto para mongod como para mongos.

Nuevo en la versión 8.0.

Tipo: booleano

Por defecto: true

Si se establece en true, tcmallocEnableBackgroundThread crea un hilo en segundo plano que periódicamente libera memoria al sistema operativo. El valor de tcmallocReleaseRate determina la tasa, en bytes por segundo, a la que el hilo en segundo plano libera memoria.

Nota

Si tcmallocEnableBackgroundThread es true y tcmallocReleaseRate es 0, MongoDB sigue liberando memoria.

Para mejorar el uso de la memoria, recomendamos utilizar el valor por defecto de true. Para obtener más información sobre las mejoras en el rendimiento y la gestión de la memoria, consulte TCMalloc mejorado.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

La siguiente operación establece tcmallocEnableBackgroundThread a false:

mongod --setParameter "tcmallocEnableBackgroundThread=false"

tcmallocReleaseRate

Disponible tanto para mongod como para mongos.

Cambiado en la versión 8.0.

Por defecto: 0

Especifica la tasa de liberación de TCMalloc en bytes por segundo. La tasa de liberación se refiere a la tasa a la que MongoDB libera memoria no utilizada al sistema. Si tcmallocReleaseRate se establece en 0, MongoDB no libera la memoria de vuelta al sistema. Aumente este valor para liberar memoria más rápidamente; redúzcalo para liberar memoria de manera más lenta.

Nota

Si tcmallocEnableBackgroundThread es true y tcmallocReleaseRate es 0, MongoDB sigue liberando memoria.

A partir de MongoDB 8.0, el valor por defecto de tcmallocReleaseRate se reduce a 0 debido a una actualización de tcmalloc que prioriza el rendimiento de la CPU sobre la liberación de memoria.

En versiones anteriores, MongoDB utilizaba una versión más antigua de tcmalloc que:

• Establezca el valor por defecto de tcmallocReleaseRate a 1.

• Valores aceptados para tcmallocReleaseRate entre 0 y 10, inclusive.

Importante

Si ejecuta MongoDB en una plataforma que utiliza tcmalloc-gperf como Windows, PPC o s390x, tcmallocReleaseRate tiene el mismo comportamiento que las versiones anteriores de MongoDB.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Para modificar la tasa de liberación durante el tiempo de ejecución, puede utilizar el comando setParameter. Por ejemplo:

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

También puede configurar tcmallocReleaseRate al inicio. Por ejemplo:

mongod --setParameter "tcmallocReleaseRate=2097152"

tcpFastOpenClient

Disponible tanto para mongod como para mongos.

Por defecto: true

Solo para el sistema operativo Linux

Habilita el soporte para conexiones salientes de TCP Fast Open (TFO) desde el mongod/mongos a un cliente. TFO requiere que tanto el cliente como la máquina host mongod/mongos soporten y habiliten TFO.

Los sistemas operativos Linux que ejecutan el Kernel de Linux 4.11 o versiones posteriores pueden dar soporte a TFO saliente.

Establezca el valor de /proc/sys/net/ipv4/tcp_fastopen para habilitar las conexiones TFO salientes:

• 1 para permitir solo las conexiones TFO salientes.

• 3 para habilitar las conexiones TFO entrantes y salientes.

Este parámetro no tiene ningún efecto si el sistema operativo del host no admite o no está configurado para admitir conexiones TFO.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Tip

RFC7413.

tcpFastOpenQueueSize

Disponible tanto para mongod como para mongos.

Por defecto: 1024

Como parte del establecimiento de una conexión TCP Fast Open (TFO), el cliente envía una cookie TFO válida a mongod/mongos antes de completar el protocolo de enlace estándar de 3 vías TCP. El mongod/mongos mantiene una cola de todas las conexiones TFO pendientes.

El parámetro tcpFastOpenQueueSize establece el tamaño de la cola de conexiones TFO pendientes. Mientras la cola está llena, el mongod/mongos vuelve al habitual apretón de manos de tres vías para las solicitudes entrantes de clientes e ignora la presencia de cookies TFO. Una vez que el tamaño de la cola vuelve a estar por debajo del límite, el mongod/mongos comienza a aceptar nuevas cookies TFO.

• Aumentar el tamaño de la cola por defecto puede mejorar el efecto de TFO en el rendimiento de la red. Sin embargo, los tamaños grandes de las colas también aumentan el riesgo de agotamiento de los recursos del servidor debido al exceso de solicitudes TFO entrantes.

• Reducir el tamaño de la cola por defecto puede disminuir el riesgo de agotamiento de los recursos del servidor debido a un exceso de solicitudes TFO entrantes. Sin embargo, los tamaños pequeños de las colas también pueden reducir el efecto de TFO en el rendimiento de la red.

  El tamaño mínimo de la cola es 0. Una cola de 0 desactiva efectivamente el TFO.

Este parámetro no tiene efecto en los sistemas operativos del host que no ofrecen soporte o no están configurados para conexiones TFO.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Tip

• RFC7413 TCP Fast Open Sección 5: Consideraciones de seguridad

• RFC7413 TCP Fast Open Sección 6: Aplicabilidad de TFO

tcpFastOpenServer

Disponible tanto para mongod como para mongos.

Por defecto: true

Habilita el soporte para aceptar conexiones entrantes de TCP Fast Open (TFO) a mongod/mongos desde un cliente. TFO requiere que tanto el cliente como la máquina host mongod/mongos soporten y habiliten TFO:

Windows

Los siguientes sistemas operativos Windows ofrecen soporte para TFO:

• Microsoft Windows servidor 2016 y versiones posteriores.

• Microsoft Windows 10 Actualización 1607 y versiones posteriores.

macOS

macOS 10.11 (El Capitan) y versiones posteriores tienen soporte para TFO.

Linux

Los sistemas operativos Linux que ejecutan Linux Kernel 3.7 o versiones posteriores pueden dar soporte a TFO entrante.

Establezca el valor de /proc/sys/net/ipv4/tcp_fastopen para habilitar las conexiones TFO entrantes:

• Establecido en 2 para permitir únicamente las conexiones TFO entrantes.

• Establecido en 3 para habilitar las conexiones TFO entrantes y salientes.

Este parámetro no tiene ningún efecto si el sistema operativo del host no admite o no está configurado para admitir conexiones TFO.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Tip

RFC7413.

ttlMonitorEnabled

Disponible solo para mongod.

Por defecto: true

Para admitir índices TTL, las instancias de mongod tienen un subproceso en segundo plano que se encarga de borrar documentos de las colecciones con índices TTL.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Para deshabilitar este subproceso de trabajo para un mongod, configure ttlMonitorEnabled en false, como en las siguientes operaciones:

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

Alternativamente, puede desactivar el hilo al iniciar la instancia mongod con la siguiente opción:

mongod --setParameter ttlMonitorEnabled=false

Importante

No ejecutes instancias de producción mongod con ttlMonitorEnabled desactivado, excepto bajo la orientación del soporte de MongoDB. Evitar la eliminación de documentos TTL puede afectar negativamente las operaciones internas del sistema de MongoDB que dependen de los índices TTL.

watchdogPeriodSeconds

Disponible solo para mongod.

Tipo: entero

Por defecto: -1 (deshabilitado)

Determina con qué frecuencia el Watchdog de nodo de almacenamiento verifica el estado de los sistemas de archivos supervisados:

• El directorio --dbpath

• El directorio journal dentro del directorio --dbpath

• El directorio del archivo --logpath

• El directorio del archivo --auditPath

Los valores válidos para watchdogPeriodSeconds son:

• -1 (por defecto), para deshabilitar/pausar el Watchdog de nodo de almacenamiento, o

• Un entero mayor o igual a 60.

Nota

• Si un sistema de archivos en un directorio supervisado no responde, puede tardar un máximo de casi el doble del valor de watchdogPeriodSeconds para terminar el mongod.

• Si alguno de sus directorios supervisados es un enlace simbólico a otros volúmenes, el Watchdog del nodo de almacenamiento no supervisa el destino del enlace simbólico. Por ejemplo, si el mongod utiliza storage.directoryPerDB: true (o --directoryperdb) y crea un enlace simbólico de un directorio de base de datos a otro volumen, el Watchdog del nodo de almacenamiento no sigue el enlace simbólico para supervisar el objetivo.

Para habilitar Storage Node Watchdog, watchdogPeriodSeconds debe configurarse durante el inicio.

mongod --setParameter watchdogPeriodSeconds=60

Solo puede habilitar el Watchdog del nodo de almacenamiento al inicio. Sin embargo, una vez habilitado, puede pausar el Watchdog de nodo de almacenamiento o cambiar el watchdogPeriodSeconds durante el tiempo de ejecución.

Una vez habilitado,

• Para pausar el Watchdog del nodo de almacenamiento durante el tiempo de ejecución, configura watchdogPeriodSeconds a -1.

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

• Para reanudar o cambiar el período durante el tiempo de ejecución, configure watchdogPeriodSeconds a un número mayor o igual a 60.

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

Nota

Es un error establecer watchdogPeriodSeconds en tiempo de ejecución si el Watchdog de nodo de almacenamiento no estaba habilitado al inicio.

Parámetros de registro

enableDetailedConnectionHealthMetricLogLines

Nuevo en la versión 7.0.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Determina si se deben habilitar mensajes de registro específicos relacionados con las métricas de salud de la conexión al clúster. Si enableDetailedConnectionHealthMetricLogLines se establece en false, los siguientes mensajes de registro se desactivan, pero MongoDB sigue recopilando datos sobre las métricas de estado de la conexión del clúster:

Mensaje de registro	Descripción
Conexión TLS aceptada desde el emparejamiento	Indica que el servidor analizó correctamente el certificado del par durante el protocolo de enlace TLS con una conexión de entrada aceptada.
Handshake TLS de entrada completado	Indica que el handshake TLS con una conexión de ingreso se ha completado.
Hola completado	Indica que el apretón de manos de conexión inicial se completó en una conexión de cliente entrante. MongoDB muestra el mensaje de registro solo con el primer comando hello.
Informe de métricas de autenticación	Especifica la finalización de un paso en la conversación de autenticación.
Se recibió el primer comando en la conexión de entrada desde el inicio de la sesión o el saludo de autenticación	Indica que una conexión de entrada recibió el primer comando que no forma parte del protocolo de enlace.
Tiempo de envío de respuesta lenta de la red	Indica que el tiempo utilizado en milisegundos para enviar la respuesta al cliente a través de una conexión de entrada es mayor que la duración definida por el parámetro del servidor slowMS.
Verificación completada del lado del cliente de la solicitud OCSP	Si el par no incluye un Respuesta deOCSP al protocolo de enlace TLS: cuando se establece una conexión TLS de salida, el servidor debe enviar una solicitud OCSP a la autoridad de certificación. MongoDB escribe este mensaje de registro cuando la autoridad de certificación recibe la respuesta OCSP.
Establecimiento lento de la conexión	Indica que el tiempo utilizado en enviar una respuesta de vuelta al cliente a través de una conexión de entrada es mayor que el umbral especificado con el parámetro slowConnectionThresholdMillis. MongoDB también emite este mensaje de registro cuando se agota el tiempo de espera para el establecimiento de la conexión.
Se agotó el tiempo de espera mientras se intentaba adquirir la conexión	Indica que una operación agotó el tiempo de espera mientras esperaba adquirir una conexión de salida.
Se adquirió la conexión para la operación remota y se completó la escritura en el bus de datos.	Indica que el servidor tardó un milisegundo o más en guardar una solicitud saliente en una conexión de salida, contando desde el instante en que se establece la conexión.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

logComponentVerbosity

Disponible tanto para mongod como para mongos.

Por defecto: 0

Configura los niveles de verbosidad de varios componentes para los mensajes de registro. El nivel de verbosidad determina la cantidad de mensajes informativos y de depuración que MongoDB emite. [2]

El nivel de verbosidad puede variar de 0 a 5:

• 0 es el nivel de verbosidad de registro por defecto de MongoDB, para incluir mensajes informativos.

• 1 a 5 aumenta el nivel de verbosidad para incluir mensajes de depuración.

Para un componente, también puede especificar -1 para heredar el nivel de verbosidad del principal.

Para especificar el nivel de verbosidad, utiliza un documento similar al siguiente:

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

Para los componentes, puede especificar solo el <component>: <int> en el documento, a menos que esté configurando tanto el nivel de verbosidad del componente principal como el de los secundarios:

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

El campo verbosity de nivel superior corresponde a systemLog.verbosity, que establece el nivel por defecto para todos los componentes. El valor por defecto de systemLog.verbosity es 0.

Los componentes se corresponden con las siguientes configuraciones:

• accessControl

• assert

• command

• control

• ftdc

• geo

• index

• network

• query

• query.rejected

• queryStats

• replication

• replication.election

• replication.heartbeats

• replication.initialSync

• replication.rollback

• recovery

• sharding

• storage

• storage.journal

• transaction

• write

A menos que se establezca explícitamente, el componente tiene el nivel de verbosidad de su principal. Por ejemplo, storage es el principal de storage.journal. Es decir, si especifica un nivel de verbosidad storage, este nivel también se aplica a:

• Componentes storage.journal a menos que especifique el nivel de verbosidad para storage.journal.

• Componentes storage.recovery a menos que especifique el nivel de verbosidad para storage.recovery.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, lo siguiente configura el default verbosity level a 1, el query a 2, el storage a 2, y el storage.journal a 1.

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

También puedes establecer el parámetro logComponentVerbosity al inicio, pasando el documento del nivel de verbosidad como un string.

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

mongosh también proporciona el db.setLogLevel() para establecer el nivel de registro de un solo componente. Para conocer las distintas formas de establecer el nivel de verbosidad del registro, consulte Configurar los niveles de verbosidad del registro.

[2]	A partir de la versión 4.2, MongoDB incluye el nivel de verbosidad de depuración (1-5) en los mensajes de registro. Por ejemplo, si el nivel de verbosidad es 2, MongoDB registra D2. En versiones anteriores, los mensajes de registro de MongoDB solo especificaban D para el nivel de depuración.

logLevel

Disponible tanto para mongod como para mongos.

Por defecto: 0 (informativo)

Especifique un número entero entre 0 y 5 que indique el nivel de verbosidad del registro, donde 5 es el más detallado. [3]

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo establece el logLevel a 2:

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

Tip

• logComponentVerbosity

• systemLog.verbosity

[3]	A partir de la versión 4.2, MongoDB incluye el nivel de verbosidad de depuración (1-5) en los mensajes de registro. Por ejemplo, si el nivel de verbosidad es 2, MongoDB registra D2. En versiones anteriores, los mensajes de registro de MongoDB solo especificaban D para el nivel de depuración.

maxLogSizeKB

Disponible tanto para mongod como para mongos.

Tipo: entero no negativo

Por defecto: 10

Especifica el tamaño máximo, en kilobytes, para un campo de atributo individual en una entrada de registro; los atributos que superen este límite se truncarán.

Los campos de atributos truncados imprimen el contenido del campo hasta el maxLogSizeKB límite y eliminan el contenido del campo más allá de ese límite, manteniendo el formato JSON válido. Las entradas de registro que contienen atributos truncados agregan un objeto truncated al final de la entrada del registro.

Consulta truncamiento de mensajes de registro para obtener más información.

Un valor de 0 desactiva por completo la truncación. Los valores negativos para este parámetro no son válidos.

Advertencia

Utilizar un valor grande, o desactivar el truncamiento con un valor de 0, puede afectar negativamente al rendimiento del sistema y tener un impacto negativo en las operaciones de la base de datos.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo establece el tamaño máximo de la línea de registro a 20 kilobytes:

mongod --setParameter maxLogSizeKB=20

quiet

Disponible tanto para mongod como para mongos.

Establece el modo de registro silencioso. Si es 1, mongod entrará en un modo de registro silencioso que no registrará los siguientes eventos/actividades:

• eventos de conexión;

• el comando drop, el comando dropIndexes, el comando validate; y

• actividades de sincronización de replicación.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Considere el siguiente ejemplo que establece el parámetro quiet a 1:

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

Tip

systemLog.quiet

redactClientLogData

Disponible tanto para mongod como para mongos.

Tipo: booleano

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

Configura el mongod o el mongos para redactar cualquier mensaje que acompañe a un evento de registro determinado antes de registrarlo. Esto impide que el programa escriba datos potencialmente sensibles almacenados en la base de datos en el registro de diagnóstico. Los metadatos, como los códigos de error u operación, las cantidades de líneas y los nombres de los archivos fuente, siguen siendo visibles en los registros.

Utilice redactClientLogData en conjunto con Cifrado en Reposo y TLS/SSL (Cifrado de Transporte) para ayudar al cumplimiento de los requisitos regulatorios.

Para habilitar la restricción de registro al iniciar, puede:

• Inicia mongod con la opción --redactClientLogData:

  mongod --redactClientLogData

• Establezca la opción security.redactClientLogData en el archivo de configuración:

  security:
     redactClientLogData: true
     ...

No puede usar la opción --setParameter para configurar redactClientLogData al inicio.

Para permitir la restricción de registro en un mongod o mongos en ejecución, utiliza el siguiente comando:

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

Tip

security.redactClientLogData

redactEncryptedFields

Nuevo en la versión 6.1.0.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Configura mongod y mongos para redactar los valores de campo de los datos cifrados de Binary de todos los mensajes de registro.

• Si el parámetro redactClientLogData o la configuración security.redactClientLogData se establece en false y redactEncryptedFields se establece en true (el valor por defecto), los campos cifrados se redactan de todos los mensajes de registro.

• Si el parámetro redactClientLogData o la configuración security.redactClientLogData se establece en true, todos los campos se redactan, independientemente de la configuración redactEncryptedFields.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

suppressNoTLSPeerCertificateWarning

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: false

Por defecto, un mongod o mongos con TLS/SSL habilitado y net.ssl.allowConnectionsWithoutCertificates : true permite a los clientes conectarse sin proporcionar un certificado para la validación mientras se registra una advertencia. Establezca suppressNoTLSPeerCertificateWarning en 1 o true para suprimir esas advertencias.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

La siguiente operación establece suppressNoTLSPeerCertificateWarning a true:

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

traceExceptions

Disponible tanto para mongod como para mongos.

Configura mongod para registrar el rastreo completo de la pila de código fuente para cada excepción de C++ de base de datos y socket, para usarlo en la depuración. Si es true, mongod registrará rastreos completos de la pila.

Este parámetro solo está disponible en tiempo de ejecución. Para establecer el parámetro, utilice el comando setParameter.

Considera el siguiente ejemplo que establece traceExceptions en true:

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

Tip

systemLog.traceAllExceptions

Parámetros de diagnóstico

Para facilitar el análisis del comportamiento del servidor MongoDB por parte de los ingenieros de MongoDB, este realiza un registro de estadísticas del servidor en archivos de diagnóstico a intervalos periódicos.

Para mongod, los archivos de datos de diagnóstico se almacenan en el directorio diagnostic.data en la instancia mongod de --dbpath o storage.dbPath.

Para mongos, los archivos de datos de diagnóstico, por defecto, se almacenan en un directorio bajo la instancia mongos en el --logpath o en el directorio systemLog.path. El directorio de datos de diagnóstico se calcula truncando las extensiones de archivo del logpath y concatenando diagnostic.data al nombre restante.

Por ejemplo, si mongos tiene --logpath /var/log/mongodb/mongos.log.201708015, entonces el directorio de datos de diagnóstico es el directorio /var/log/mongodb/mongos.diagnostic.data/. Para especificar un directorio de datos de diagnóstico diferente para mongos, establece el parámetro diagnosticDataCollectionDirectoryPath.

Los siguientes parámetros admiten la captura de datos de diagnóstico (FTDC):

diagnosticDataCollectionDirectoryPath

Disponible solo para mongos.

Tipo: string

Advertencia

Si la captura de datos de diagnóstico en tiempo completo (FTDC) está deshabilitada con diagnosticDataCollectionEnabled o si systemLog.destination está configurada en syslog, debes reiniciar mongos después de configurar diagnosticDataCollectionDirectoryPath.

Especifique el directorio para el directorio de diagnóstico de mongos. Si el directorio no existe, mongos creará el directorio.

Si no se especifica, el directorio de datos de diagnóstico se calcula truncando la extensión de archivo de la instancia mongos --logpath o systemLog.path y concatenando diagnostic.data.

Por ejemplo, si mongos tiene --logpath /var/log/mongodb/mongos.log.201708015, entonces el directorio de datos de diagnóstico es /var/log/mongodb/mongos.diagnostic.data/.

Si el mongos no puede crear el directorio especificado, la captura de datos de diagnóstico se desactiva para esa instancia. mongos podría no ser capaz de crear el directorio especificado si ya existe un archivo con el mismo nombre en la ruta o si el proceso no tiene permisos para crear el directorio.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

diagnosticDataCollectionDirectorySizeMB

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 250 (500 en clústeres particionados)

Especifica el tamaño máximo, en megabytes, del directorio diagnostic.data. Si el tamaño del directorio supera este número, los archivos de diagnóstico más antiguos del directorio se borran automáticamente según la marca de tiempo en el nombre del archivo.

Cambiado en la versión 8.0: diagnosticDataCollectionDirectorySizeMB tiene un valor por defecto de 400 MB para las instancias mongos y mongod utilizadas en clústeres particionados. Las instancias mongod utilizadas en el set de réplicas o como servidores autónomos tienen un valor por defecto de 200 MB.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, el siguiente comando establece el tamaño máximo del directorio a 250 megabytes:

mongod --setParameter diagnosticDataCollectionDirectorySizeMB=250

El valor mínimo para diagnosticDataCollectionDirectorySizeMB es 10 megabytes. diagnosticDataCollectionDirectorySizeMB debe ser mayor que el tamaño máximo del archivo de diagnóstico diagnosticDataCollectionFileSizeMB.

diagnosticDataCollectionEnabled

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Determina si se debe habilitar la recopilación y el registro de datos con fines de diagnóstico. El registro de diagnóstico está habilitado por defecto.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, lo siguiente desactiva la colección de diagnósticos:

mongod --setParameter diagnosticDataCollectionEnabled=false

diagnosticDataCollectionFileSizeMB

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 10

Especifica el tamaño máximo, en megabytes, de cada archivo de diagnóstico. Si el archivo supera el tamaño máximo permitido, MongoDB crea un nuevo archivo.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, el siguiente establece el tamaño máximo de cada archivo de diagnóstico en 20 megabytes:

mongod --setParameter diagnosticDataCollectionFileSizeMB=20

El valor mínimo para diagnosticDataCollectionFileSizeMB es 1 megabyte.

diagnosticDataCollectionPeriodMillis

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 1000

Especifica el intervalo, en milisegundos, a intervalos en los que se deben recopilar los datos de diagnóstico.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, el siguiente establece el intervalo a 5000 milisegundos o 5 segundos:

mongod --setParameter diagnosticDataCollectionPeriodMillis=5000

El valor mínimo para diagnosticDataCollectionPeriodMillis es 100 milisegundos.

Replicación y coherencia

allowMultipleArbiters

Novedades en la versión 5.3.

Disponible solo para mongod.

Tipo: booleano

Por defecto: false

Especifica si el set de réplicas permite el uso de múltiples árbitros.

No se recomienda el uso de múltiples árbitros:

• Varios árbitros impiden el uso confiable del nivel de confirmación de escritura de mayoría. MongoDB cuenta a los árbitros al calcular la mayoría de los miembros, pero los árbitros no almacenan datos. Al incluir varios árbitros, es posible que una operación de escritura de mayoría devuelva éxito antes de que la escritura se replique en la mayoría de los nodos que contienen datos.

• Tener varios árbitros permite que los sets de réplicas acepten escrituras incluso cuando el set de réplicas no tiene suficientes secundarios para la replicación de datos.

Para obtener más información, consulta Problemas con múltiples árbitros.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

mongod --setParameter allowMultipleArbiters=true

connectTimeoutMs

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 10000

Establece el tiempo de espera de la conexión en milisegundos para el supervisor del set de réplicas.

Este parámetro solo está disponible al inicio. Si establece este parámetro, debe ser mayor o igual a 500.

El siguiente ejemplo establece connectTimeoutMs para una instancia de mongod a 700 milisegundos:

mongod --setParameter connectTimeoutMs=700

createRollbackDataFiles

Disponible solo para mongod.

Tipo: booleano

Por defecto: true

Indicador que determina si MongoDB crea archivos de rollback que contengan documentos afectados durante un rollback.

Por defecto, createRollbackDataFiles es true y MongoDB crea los archivos de rollback.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo configura createRollbackDataFiles en falso para que no se creen los archivos de rollback:

mongod --setParameter createRollbackDataFiles=false

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

Para obtener más información, consulte la Recopilación de datos de rollback.

disableSplitHorizonIPCheck

Novedades en la versión 5.0.0.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: false

Para configurar los nodos del clúster para DNS de horizonte dividido, utiliza nombres de host en lugar de direcciones IP.

A partir de MongoDB v5.0, replSetInitiate y replSetReconfig rechazarán las configuraciones que utilicen direcciones IP en lugar de nombres de host.

Utiliza disableSplitHorizonIPCheck para modificar nodos que no se pueden actualizar para usar nombres de host. El parámetro solo se aplica a los comandos de configuración.

mongod y mongos no dependen de disableSplitHorizonIPCheck para la validación al inicio. Las instancias mongod y mongos heredadas que utilizan direcciones IP en lugar de nombres de host pueden iniciarse después de una actualización.

Las instancias configuradas con direcciones IP generan un registro de advertencia para que se usen nombres de host en lugar de direcciones IP.

Para permitir cambios de configuración mediante direcciones IP, configure disableSplitHorizonIPCheck=true con la línea de comandos:

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

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

setParameter:
   disableSplitHorizonIPCheck: true

enableFlowControl

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Habilita o deshabilita el mecanismo que controla la tasa a la que el primario aplica sus guardados con el objetivo de mantener la demora de los nodos secundarios majority committed por debajo de un valor máximo configurable.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

enableOverrideClusterChainingSetting

Nuevo en la versión 5.0.2.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: false

Si enableOverrideClusterChainingSetting está true, los miembros secundarios del Set de réplicas pueden replicar datos de otros miembros secundarios incluso si settings.chainingAllowed está false.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el enableOverrideClusterChainingSetting para una instancia de mongod a true:

mongod --setParameter enableOverrideClusterChainingSetting=true

flowControlTargetLagSeconds

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 10

La demora máxima objetivo es majority committed al ejecutar con control de flujo. Cuando el control de flujo está habilitado, el mecanismo intenta mantener la demora majority committed por debajo de los segundos especificados. El parámetro no tiene efecto si el control de flujo está deshabilitado.

El valor especificado debe ser mayor que 0.

En general, la configuración por defecto debería ser suficiente. Sin embargo, si se modifica desde el valor por defecto, disminuir en lugar de aumentar el valor puede resultar más útil.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

flowControlWarnThresholdSeconds

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 10

La cantidad de tiempo que se debe esperar para hacer un registro de advertencia una vez que el mecanismo de control de flujo detecta que el punto de confirmación de la mayoría no se ha movido.

El valor especificado debe ser mayor o igual a 0, con 0 para desactivar las advertencias.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

heartBeatFrequencyMs

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 10000

Cuando replicaSetMonitorProtocol se establece en 'sdam', heartBeatFrequencyMs determina cuánto tiempo, en milisegundos, se espera entre las solicitudes de hello.

Cuando replicaSetMonitorProtocol se establece en 'streamable', heartBeatFrequencyMs determina cuánto tiempo, en milisegundos, se debe esperar entre las mediciones de tiempo de ida y vuelta (RTT) de hello. Las mediciones de RTT se utilizan en la selección de servidores.

Este parámetro solo está disponible al inicio. Si establece este parámetro, debe ser mayor o igual a 500.

El siguiente ejemplo configura heartBeatFrequencyMs en una instancia de mongod a 700 milisegundos:

mongod --setParameter heartBeatFrequencyMs=700

initialSyncIndexBuildMemoryPercentage

Nuevo en la versión 8.2: (y 8.0.13, 7.0.26)

Disponible solo para mongod.

Tipo: doble

Por defecto: 10.0

El porcentaje de memoria del sistema que MongoDB asigna para la creación de índices durante la sincronización inicial. La cantidad de memoria del sistema utilizada está limitada por los valores de initialSyncIndexBuildMemoryMinMB y initialSyncIndexBuildMemoryMaxMB.

Puede especificar un valor entre 0.0 y 80.0, inclusive.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, para establecer initialSyncIndexBuildMemoryPercentage para una instancia de mongod al 40 %:

mongod --setParameter initialSyncIndexBuildMemoryPercentage=40

initialSyncIndexBuildMemoryMaxMB

Nuevo en la versión 8.2: (y 8.0.13, 7.0.26)

Disponible solo para mongod.

Tipo: entero

Por defecto: 16384

La cantidad máxima de memoria del sistema, en megabytes, que MongoDB puede usar para la creación de índices durante la sincronización inicial.

Puede especificar un valor entre 50 y 10000000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, para establecer el initialSyncIndexBuildMemoryMaxMB para una instancia de mongod a 20000 MB:

mongod --setParameter initialSyncIndexBuildMemoryMaxMB=20000

initialSyncIndexBuildMemoryMinMB

Nuevo en la versión 8.2: (y 8.0.13, 7.0.26)

Disponible solo para mongod.

Tipo: entero

Por defecto: 200

La cantidad mínima de memoria del sistema, en megabytes, que MongoDB puede utilizar para la creación de índices durante la sincronización inicial.

Puede especificar un valor entre 50 y 10000000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Por ejemplo, para establecer el initialSyncIndexBuildMemoryMinMB para una instancia de mongod a 60 MB:

mongod --setParameter initialSyncIndexBuildMemoryMinMB=60

initialSyncMethod

Nuevo en la versión 5.2.

Disponible solo para mongod.

Tipo: string

Por defecto: logical

Disponible únicamente en MongoDB Enterprise.

Método utilizado para la sincronización inicial.

Establezca en logical para usar la sincronización inicial lógica. Establezca en fileCopyBased para usar la sincronización inicial basada en copia de archivos.

Este parámetro solo afecta al método de sincronización de los nodos en los que se especifica. Configurar este parámetro en un único nodo del set de réplicas no afecta el método de sincronización de ningún otro nodo del set de réplicas.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Si el parámetro para el initialSyncMethod clúster fileCopyBased es, entonces no hay impacto en los oyentes del flujo de cambios.

Si initialSyncMethod es logical y se abre un flujo de cambio en un nodo recién sincronizado y lee eventos de un punto en el tiempo anterior a la finalización de la sincronización inicial lógica, es posible que falten las imágenes previas y posteriores.

initialSyncSourceReadPreference

Disponible solo para mongod.

Tipo: string

La fuente preferida para realizar la sincronización inicial. Especifique uno de los siguientes modos de preferencia de lectura:

• primary

• primaryPreferred (Por defecto para los miembros votantes del set de réplicas)

• secondary

• secondaryPreferred

• nearest (por defecto para los nodos recién agregados o no votantes del set de réplicas)

Si el set de réplicas ha deshabilitado chaining, el modo de preferencia de lectura por defecto initialSyncSourceReadPreference es primary.

No puede especificar un conjunto de etiquetas o maxStalenessSeconds para initialSyncSourceReadPreference.

Si el mongod no puede encontrar una fuente de sincronización basada en la preferencia de lectura especificada, registra un error y reinicia el proceso de sincronización inicial. El mongod termina con un error si no puede completar el proceso de sincronización inicial después de 10 intentos. Para obtener más información sobre la selección de la fuente de sincronización, consulte la Selección de la fuente de sincronización inicial.

initialSyncSourceReadPreference tiene prioridad sobre la configuración settings.chainingAllowed del conjunto de réplicas al seleccionar una fuente de sincronización inicial. Después de que un miembro del set de réplicas complete con éxito la sincronización inicial, se remite al valor de chainingAllowed al seleccionar una fuente de sincronización de replicación.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

initialSyncTransientErrorRetryPeriodSeconds

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 86400

La cantidad de tiempo en segundos que un secundario que realiza la sincronización inicial intenta reanudar el proceso si es interrumpido por un error transitorio de red. El valor por defecto es equivalente a 24 horas.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

localLogicalSessionTimeoutMinutes

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 30

Advertencia

Solo para fines de prueba

Este parámetro está destinado únicamente a fines de prueba y no para uso en producción.

El tiempo en minutos que una sesión permanece activa después de su uso más reciente. Las sesiones que no hayan recibido una nueva operación de lectura/guardado del cliente o que no se hayan actualizado con refreshSessions dentro de este umbral se eliminan de la caché. El servidor puede limpiar el estado asociado a una sesión caducada en cualquier momento.

Este parámetro se aplica solo a la instancia en la que está configurado. Para establecer este parámetro en sets de réplicas y clústeres particionados, debe especificar el mismo valor en cada nodo. De lo contrario, las sesiones no funcionarán correctamente.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el localLogicalSessionTimeoutMinutes para una instancia de prueba mongod a 20 minutos:

mongod --setParameter localLogicalSessionTimeoutMinutes=20

localThresholdMs

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 15

Define la longitud de la ventana de latencia utilizada en la selección del servidor en milisegundos.

Este parámetro solo está disponible al inicio. Si establece este parámetro, debe ser mayor o igual a 0.

El siguiente ejemplo establece localThresholdMs para una instancia de mongod a 20 milisegundos:

mongod --setParameter localThresholdMs=20

logicalSessionRefreshMillis

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 300000 (5 minutos)

El intervalo (en milisegundos) en el que la caché actualiza sus registros lógicos de sesión en comparación con el almacén principal de la sesión.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el logicalSessionRefreshMillis para una instancia de mongod a 10 minutos:

mongod --setParameter logicalSessionRefreshMillis=600000

maxAcceptableLogicalClockDriftSecs

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 31536000 (1 año)

La cantidad máxima en la que se puede adelantar el tiempo del clúster actual; específicamente, maxAcceptableLogicalClockDriftSecs es la diferencia máxima entre el nuevo valor del tiempo del clúster y el tiempo del clúster actual. El tiempo de clúster es un tiempo lógico utilizado para el ordenamiento de operaciones.

No puede avanzar el tiempo del clúster a un nuevo valor si el nuevo tiempo del clúster difiere del tiempo actual del clúster en más de maxAcceptableLogicalClockDriftSecs.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el maxAcceptableLogicalClockDriftSecs para una instancia de mongod a 15 minutos:

mongod --setParameter maxAcceptableLogicalClockDriftSecs=900

maxNumSyncSourceChangesPerHour

Disponible tanto para mongod como para mongos.

Nuevo en la versión 5.0.

Tipo: entero

Por defecto: 3

Las fuentes de sincronización se evalúan cada vez que se actualiza una fuente de sincronización y cada vez que un nodo obtiene un lote de entradas de oplog. Si hay más de maxNumSyncSourceChangesPerHour cambios en la fuente en una hora, el nodo deja temporalmente de reevaluar esa fuente de sincronización. Si este parámetro se establece con un valor alto, es posible que el nodo realice cambios innecesarios en la fuente.

Este parámetro no impedirá que un nodo comience a sincronizarse desde otro nodo si no tiene una fuente de sincronización. El nodo volverá a evaluar si una fuente de sincronización se vuelve no válida. De manera similar, si el nodo primario cambia y el encadenamiento está desactivado, el nodo se actualizará para sincronizarse con el nuevo nodo primario.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

maxSessions

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 1000000

La cantidad máxima de sesiones que se pueden almacenar en caché.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el maxSessions para una instancia de mongod a 1000:

mongod --setParameter maxSessions=1000

mirrorReads

Disponible solo para mongod.

Tipo: documento

Por defecto: { samplingRate: 0.01, maxTimeMS: 1000 }

Especifica la configuración de las lecturas espejeadas para la instancia de mongod. La configuración solo surte efecto cuando el nodo es primario.

El parámetro mirrorReads acepta un documento JSON con los siguientes campos:

Campo	Descripción
samplingRate	La tasa de muestreo utilizada para reflejar un subconjunto de operaciones que soportan la replicación a un subconjunto de secundarios elegibles (específicamente, priority greater than 0). Es decir, los espejos primarios envían lecturas a cada secundario elegible a la tasa de muestreo especificada. Los valores válidos son: 0.0 Desactiva las lecturas espejadas. 1.0 El primario refleja todas las operaciones que admiten el espejado a cada secundario elegible. Número entre 0.0 y 1.0 (exclusivo) El nodo primario toma muestras aleatorias de cada nodo secundario elegible a la tasa especificada para enviar lecturas espejeadas. Por ejemplo, dado un set de réplicas con un primario y dos secundarios elegibles, y una velocidad de muestreo de 0.10, el primario replica las lecturas a cada secundario elegible con una velocidad de muestreo del 10 %, de modo que una lectura puede replicarse a un secundario y no al otro, a ambos o a ninguno. Es decir, si el primario recibe 100 operaciones que se pueden reflejar, la velocidad de muestreo de 0.10 puede dar lugar a que 8 lecturas se reflejen en un secundario y 13 lecturas en el otro o 10 en cada uno, etc. El valor por defecto es 0.01.
maxTimeMS	El tiempo máximo en milisegundos para las lecturas espejeadas. El valor por defecto es 1000. El maxTimeMS para las lecturas espejeadas es independiente del maxTimeMS de la lectura original que se está espejeando.
targetedMirroring	Contiene campos para configurar cómo se dirige a nodos específicos para el calentamiento de la caché. Consulte Lecturas espejeadas dirigidas para obtener más información. Incluye los siguientes campos: tag Se establece por defecto en un BSONObj vacío. La etiqueta de set de réplicas que puede usar para dirigir nodos para la lectura espejada. Puede configurar un nodo para la lectura espejada dirigida con la siguiente sintaxis: tag: { "<tag1>": "<string1>" } Solo puede suministrar una etiqueta. Se seleccionan todos los nodos dentro del mismo set de réplicas que tengan estas etiquetas. samplingRate Tipo: float Rango: 0.0 a 1.0 (incluido) La tasa a la que las lecturas dirigidas se reflejan en el host o los hosts. Una tasa de 0.0 significa que no hay lecturas espejadas, y una tasa de 1.0 significa que todas las lecturas son espejadas. Si bien samplingRate es 0.01 por defecto, la característica targetedMirroring está desactivada, ya que el campo tag está vacío por defecto. maxTimeMS Tipo: int El tiempo máximo en milisegundos antes de que se agote el tiempo de espera de la lectura espejeada. El valor mínimo para maxTimeMS es 0. Se establece por defecto en 1000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Si lo especificas desde el archivo de configuración o desde la línea de comandos, encierra el mirrorReads documento entre comillas.

Por ejemplo, lo siguiente establece la tasa de muestreo de lecturas espejo a 0.10 desde la línea de comandos:

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

O, para especificar en un archivo de configuración:

setParameter:
   mirrorReads: '{samplingRate: 0.10}'

O si utiliza el comando setParameter en una sesión mongosh que está conectada a un mongod en ejecución, no encierre el documento entre comillas:

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

mirrorReadsMaxConnPoolSize

Nuevo en la versión 8.2.

Tipo: int

Por defecto: 4

Controla el número máximo de conexiones en el grupo de reflejo. Este parámetro afecta tanto a las lecturas espejeadas generales como a las dirigidas. mirrorReadsMaxConnPoolSize tiene un valor mínimo de 1.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

oplogBatchDelayMillis

Novedades en la versión 6.0.

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 0

La cantidad de milisegundos para demorar la aplicación de agrupación de operaciones oplog en nodos secundarios. Por defecto, oplogBatchDelayMillis es 0, lo que significa que las agrupaciones de oplog se aplican sin demoras. Cuando no hay demoras, MongoDB puede aplicar las agrupaciones pequeñas y frecuentes de oplog a los secundarios.

Incrementar oplogBatchDelayMillis hace que MongoDB aplique lotes de oplog con menor frecuencia en los secundarios, donde cada lote contiene mayores cantidades de datos. Esto reduce IOPS en los secundarios, pero agrega latencia para las escrituras con nivel de confirmación de escritura "majority".

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, ejecute el siguiente comando para establecer el oplogBatchDelayMillis para una instancia de mongod en 20 milisegundos:

mongod --setParameter oplogBatchDelayMillis=20

oplogFetcherUsesExhaust

Disponible solo para mongod.

Tipo: booleano

Por defecto: true

Activa o desactiva la replicación de streaming. Establezca el valor en true para habilitar la replicación de streaming.

Establece el valor en false para desactivar la replicación de streaming. Si está deshabilitado, los secundarios obtienen lotes de entradas de oplog al enviar una solicitud a su sincronización desde la fuente y esperar una respuesta. Esto requiere un recorrido de ida y vuelta a la red para cada agrupación de entradas de oplog.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

oplogInitialFindMaxSeconds

Disponible solo para mongod.

Tipo: entero

Por defecto: 60

Tiempo máximo en segundos para que un nodo de un set de réplicas espere a que el comando find termine durante la sincronización de datos.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

periodicNoopIntervalSecs

Disponible solo para mongod.

Tipo: entero

Por defecto: 10

La duración en segundos entre las escrituras noop en cada nodo individual.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Nota

Para modificar este valor para un clúster de MongoDB Atlas, debe ponerse en contacto con el soporte de Atlas.

El siguiente ejemplo configura el periodicNoopIntervalSecs a 1 segundo durante la iniciación:

mongod --setParameter periodicNoopIntervalSecs=1

replBatchLimitBytes

Disponible tanto para mongod como para mongos.

Default: 104857600 (100MB)

Establece el tamaño máximo de la agrupación de aplicaciones del oplog en bytes.

Los valores pueden estar en un rango de 16777216 (16 MB) a 104857600 (100 MB), inclusive.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo configura replBatchLimitBytes a 64 MB para limitar el tamaño de agrupación de la aplicación de oplog:

mongod --setParameter replBatchLimitBytes=67108864

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

replicaSetMonitorProtocol

Disponible tanto para mongod como para mongos.

Tipo: string

Por defecto: "transmitible"

Determina qué protocolo de la supervisión del set de réplicas se debe utilizar. Puedes establecer este parámetro en "streamable", que cumple con la especificación de descubrimiento y supervisión de servidores (SDAM) y permite solicitudes hello constantes. También puedes establecer este parámetro en "sdam", que cumple con la especificación SDAM.

Este parámetro solo está disponible al inicio.

El siguiente ejemplo establece replicaSetMonitorProtocol en "sdam" en una instancia de mongod:

mongod --setParameter replicaSetMonitorProtocol='sdam'

replWriterMinThreadCount

Nuevo en la versión 5.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 0

Número mínimo de hilos que se deben utilizar para aplicar operaciones replicadas en paralelo. Los valores pueden estar en el rango de 0 a 256 inclusive. Solo puede configurar replWriterMinThreadCount al inicio y no puede cambiar esta configuración con el comando setParameter.

La aplicación paralela de las operaciones de replicación utiliza hasta replWriterThreadCount subprocesos. Si replWriterMinThreadCount se configura con un valor inferior a replWriterThreadCount, el grupo de subprocesos agotará los subprocesos inactivos hasta que la cantidad total de subprocesos en el grupo sea igual a replWriterMinThreadCount.

replWriterMinThreadCount debe configurarse con un valor que sea menor o igual a replWriterThreadCount.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

replWriterThreadCount

Disponible solo para mongod.

Tipo: entero

Por defecto: 16

Número máximo de hilos que se deben utilizar para aplicar operaciones replicadas en paralelo. Los valores pueden estar en el rango de 1 a 256 inclusive. Sin embargo, el número máximo de hilos utilizados está limitado a dos veces el número de núcleos disponibles.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Tip

replWriterMinThreadCount

rollbackTimeLimitSecs

Disponible solo para mongod.

Tipo: entero de 64 bits

Por defecto: 86400 (1 día)

Antigüedad máxima de los datos que se pueden deshacer. Los valores negativos para este parámetro no son válidos.

Si el tiempo entre el final del oplog de la instancia que se va a revertir y la primera operación después del punto común (el último punto donde el nodo de origen y el nodo que se va a revertir tenían los mismos datos) supera este valor, el rollback fallará.

Para tener efectivamente un periodo de rollback ilimitado, fije el valor a 2147483647, que es el valor máximo permitido y equivale a aproximadamente 68 años.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

TransactionRecordMinimumLifetimeMinutes

Disponible solo para mongod.

Tipo: entero

Por defecto: 30

El tiempo mínimo que un registro de transacción permanece en la colección transactions antes de que el registro sea elegible para la limpieza.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

Por ejemplo, para establecer el TransactionRecordMinimumLifetimeMinutes para una instancia de mongod a 20 minutos:

mongod --setParameter TransactionRecordMinimumLifetimeMinutes=20

Tip

localLogicalSessionTimeoutMinutes

waitForSecondaryBeforeNoopWriteMS

Disponible solo para mongod.

Tipo: entero

Por defecto: 10

La duración (en milisegundos) que un secundario debe esperar si el afterClusterTime es mayor que el último tiempo aplicado del oplog. Después de que el waitForSecondaryBeforeNoopWriteMS pase, si el afterClusterTime sigue siendo mayor que el último tiempo aplicado, el secundario realiza un guardado no operativo para avanzar el último tiempo aplicado.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo configura el waitForSecondaryBeforeNoopWriteMS a 20 milisegundos:

mongod --setParameter waitForSecondaryBeforeNoopWriteMS=20

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

Parámetros de partición

analyzeShardKeyCharacteristicsDefaultSampleSize

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 10000000

Si sampleRate y sampleSize no están configurados cuando ejecutas analyzeShardKey, especifica el número de documentos a muestrear al calcular las métricas de características de la clave de fragmentación. Debe ser mayor que 0.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo estableceanalyzeShardKeyCharacteristicsDefaultSampleSize en 10000 durante la iniciación:

mongod --setParameter analyzeShardKeyCharacteristicsDefaultSampleSize=10000

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

analyzeShardKeyMonotonicityCorrelationCoefficientThreshold

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: doble

Por defecto: 0,7

Especifica el umbral del coeficiente de correlación RecordId utilizado para determinar si una clave de fragmentación cambia de manera monótona en el orden de inserción. Debe ser mayor que 0 y menor o igual a 1.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo estableceanalyzeShardKeyMonotonicityCorrelationCoefficientThreshold en 1 durante la iniciación:

mongod --setParameter analyzeShardKeyMonotonicityCorrelationCoefficientThreshold=1

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

analyzeShardKeyNumMostCommonValues

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 5

Especifica el número de valores de clave de fragmentación más comunes que se deben devolver. Si la colección contiene menos claves de fragmentación únicas que este valor, analyzeShardKeyNumMostCommonValues devuelve ese número de valores más comunes. Debe ser mayor que 0 y menor o igual a 1000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo estableceanalyzeShardKeyNumMostCommonValues en 3 durante la iniciación:

mongod --setParameter analyzeShardKeyNumMostCommonValues=3

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

analyzeShardKeyNumRanges

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 100

Especifica el número de rangos en los que se debe particionar el espacio de clave de fragmentación al calcular el calentamiento de los rangos de clave de fragmentación. Debe ser mayor que 0 y menor o igual a 10000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo estableceanalyzeShardKeyNumRanges en 50 durante la iniciación:

mongod --setParameter analyzeShardKeyNumRanges=50

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

analyzeShardKeyNumSamplesPerRange

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero no negativo

Por defecto: 10

El número de documentos que se van a muestrear por rango de clave de partición debe ser un valor mayor que cero y menor o igual a 10000.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo estableceanalyzeShardKeyNumSamplesPerRange en 50 durante la iniciación:

mongod --setParameter analyzeShardKeyNumSamplesPerRange=50

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

autoMergerIntervalSecs

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 3600

Cuando AutoMerger está habilitado, especifica el intervalo de tiempo entre las rondas de autofusión, en segundos. El valor por defecto es 3600 segundos, o una hora.

autoMergerIntervalSecs solo se puede configurar en servidores de configuración.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo establece autoMergerIntervalSecs en 7200 segundos, o dos horas, durante la iniciación:

mongod --setParameter autoMergerIntervalSecs=7200

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

autoMergerThrottlingMS

Nuevo en la versión 7.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 15000

Cuando AutoMerger está habilitado, especifica la cantidad mínima de tiempo entre las fusiones iniciadas por el AutoMerger en la misma colección, en milisegundos.

autoMergerThrottlingMS solo se puede configurar en servidores de configuración.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo establece autoMergerThrottlingMS en 60000 milisegundos, o un minuto, durante la iniciación:

mongod --setParameter autoMergerThrottlingMS=60000

Durante el tiempo de ejecución, puedes establecer o modificar el parámetro con el comando setParameter:

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

balancerMigrationsThrottlingMs

Nuevo en la versión 7.0: (También disponible a partir de las versiones 6.3.1, 6.0.6, 5.0.18)

Disponible solo para mongod.

Tipo: entero

Por defecto: 1000

Se debe especificar el tiempo mínimo entre dos rondas de balanceo consecutivas. Esto permite regular la velocidad de balanceo. Este parámetro solo surte efecto en los nodos del servidor de configuración.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

Este ejemplo establece balancerMigrationsThrottlingMs en 2000 milisegundos durante la iniciación:

mongod --setParameter balancerMigrationsThrottlingMs=2000

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

catalogCacheCollectionMaxEntries

Nuevo en la versión 8.1: (también disponible a partir de 8.0.10, 7.0.22)

Tipo: entero

Por defecto: 10000

Disponible tanto para mongod como para mongos.

Número máximo de entradas permitidas en la caché del catálogo para colecciones.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

catalogCacheDatabaseMaxEntries

Nuevo en la versión 8.1: (también disponible a partir de 8.0.10, 7.0.22)

Tipo: entero

Por defecto: 10000

Disponible tanto para mongod como para mongos.

Cantidad máxima de entradas que se permiten en la caché del catálogo para bases de datos.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

chunkDefragmentationThrottlingMS

Novedades en la versión 5.3.

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 0

Especifica el período de tiempo mínimo (en milisegundos) entre los comandos consecutivos de división y fusión ejecutados por el balanceador cuando se desfragmentan los fragmentos en una colección particionada. chunkDefragmentationThrottlingMS limita la velocidad de los comandos de división y fusión.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo establece chunkDefragmentationThrottlingMS a 10 milisegundos:

mongod --setParameter chunkDefragmentationThrottlingMS=10

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

directConnectionChecksWithSingleShard

Nuevo en la versión 7.0.12.

Disponible solo para mongod.

Tipo: booleano

Por defecto: verdadero a partir de MongoDB 8.0.10

Cuando se configura en un clúster particionado con una sola partición, se activan las advertencias de conexión directa. Si un usuario se conecta directamente al clúster de una sola partición, mongod registra una advertencia cada hora y actualiza shardingStatstics.unauthorizedDirectShardOps con operaciones directas de partición no autorizadas.

Para evitar esto, los usuarios deberían conectarse a clústeres de una sola partición a través de un enrutador, como mongos.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

disableResumableRangeDeleter

Disponible solo para mongod.

Tipo: booleano

Por defecto: false

Si se establece en el primario de una partición, especifica si MongoDB pausa la eliminación de rangos en la partición. Si se establece en true, MongoDB pausa la limpieza de rangos que contienen documentos huérfanos. La partición puede seguir donando fragmentos a otras particiones, pero no remueve los documentos donados hasta que establezca este parámetro en false. Esta partición puede seguir recibiendo fragmentos de otras particiones siempre que no tenga una tarea pendiente de eliminación de rango en la colección config.rangeDeletions que se superponga con el rango del fragmento entrante.

Cuando disableResumableRangeDeleter es true, las migraciones de fragmentos fallan si existen documentos huérfanos en el primario del fragmento receptor en el mismo rango que los fragmentos entrantes.

El parámetro no tiene efecto en el mongod si no es el primario del fragmento.

Importante

Si estableces el parámetro disableResumableRangeDeleter en true, asegúrate de aplicarlo de manera consistente para todos los miembros en el set de réplicas de la partición. En caso de un error, el valor de esta configuración en el nuevo primario dicta el comportamiento del eliminador de rango.

A partir de MongoDB 8.2, puede configurar disableResumableRangeDeleter tanto durante el inicio como en tiempo de ejecución.

Para establecer disableResumableRangeDeleter al inicio, utilice el siguiente comando:

mongod --setParameter disableResumableRangeDeleter=false

Para establecer disableResumableRangeDeleter durante la ejecución, utilice el siguiente comando:

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

enableFinerGrainedCatalogCacheRefresh

Nota

Obsoleto en 8.0

A partir de MongoDB 8.0, el parámetro queda en desuso y no provoca cambios ni errores.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Este parámetro permite que la caché del catálogo se actualice solo si se necesita actualizar la partición. Si está deshabilitado, cualquier fragmento obsoleto hará que toda la distribución de fragmentos para una colección se considere obsoleta y obligará a todos los enrutadores que se pongan en contacto con la partición a actualizar su caché de catálogo de particiones.

Este parámetro solo está disponible al inicio. Para establecer el parámetro, utilice la configuración setParameter.

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

Tip

• particionado

• shardingStatistics.catalogCache

enableShardedIndexConsistencyCheck

Disponible solo para mongod.

Tipo: booleano

Por defecto: true

Si se establece en el primario del servidor de configuración, habilita o deshabilita la verificación de coherencia del índice para colecciones fragmentadas. El parámetro no tiene efecto en el mongod si no es el servidor de configuración primario.

Este parámetro está disponible tanto en tiempo de ejecución como al inicio:

• Para establecer el parámetro en tiempo de ejecución, utiliza el comando setParameter.

• Para establecer el parámetro al inicio, utiliza la configuración setParameter.

El siguiente ejemplo establece enableShardedIndexConsistencyCheck a false para un servidor de configuración primario:

mongod --setParameter enableShardedIndexConsistencyCheck=false

Durante el tiempo de ejecución, también puedes establecer el parámetro con el comando setParameter:

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

Tip

• shardedIndexConsistencyCheckIntervalMS parameter

• shardedIndexConsistency métricas devueltas por el comando serverStatus.