/ /

Administración

Configuración y mantenimiento

Docs Home

Manual de base de datos

Implementaciones autogestionadas

Administración

Configuración y mantenimiento

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

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

Synopsis

MongoDB proporciona una serie de opciones de configuración que puedes establecer con:

el setParameter dominio:
```
db.adminCommand( { setParameter: 1, <parameter>: <value>  } )
```
la configuración de setParameter:
```
setParameter:
   <parameter1>: <value1>
   ...
```
la opción de línea de comandos --setParameter para mongod y mongos:
```
mongod --setParameter <parameter>=<value>
mongos --setParameter <parameter>=<value>
```

Para opciones adicionales de configuración, consulte Opciones del archivo de configuración autogestionado, mongod y mongos.

Parámetros

Parámetros de autenticación

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	Solicitud de comentarios 5802 Mecanismo de autenticación de respuesta de desafío salado estándar que utiliza la función 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.

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

awsSTSRetryCount

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

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 mongod y mongos para TLS/SSL 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.

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.

KeysRotationIntervalSec

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.

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

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

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

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

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 usar con implementaciones de MongoDB que utilizan autorización LDAP en implementaciones autogestionadas. Disponible mongod solo para instancias.

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

ldapUseConnectionPool

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.

ldapConnectionPoolUseLatencyForHostPriority

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 durante el inicio y no puede cambiar esta ldapConnectionPoolUseLatencyForHostPriority setParameter configuración durante el tiempo de ejecución con el comando de base de datos.

ldapConnectionPoolMinimumConnectionsPerHost

Por defecto: 1

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

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

ldapConnectionPoolMaximumConnectionsPerHost

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 durante el inicio y no puede cambiar esta ldapConnectionPoolMaximumConnectionsPerHost setParameter configuración durante el tiempo de ejecución con el comando de base de datos.

ldapConnectionPoolMaximumConnectionsInProgressPerHost

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.

ldapConnectionPoolHostRefreshIntervalMillis

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

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.

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

maxValidateMemoryUsageMB

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

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

opensslCipherConfig

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

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

saslauthdPath

Nota

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

Disponible tanto para mongod como para mongos.

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:

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

Por defecto: 10000

Disponible tanto para mongod como para mongos.

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

scramSHA256IterationCount

Por defecto: 15000

Disponible tanto para mongod como para mongos.

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

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 mongod y mongos para TLS/SSL 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

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 mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes.

Tip

sslMode

tlsOCSPStaplingTimeoutSecs

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 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 mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes.

tlsWithholdClientCertificate

Disponible tanto para mongod como para mongos.

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.

Puede usar este parámetro para actualizar progresivamente los certificados con nuevos certificados que contengan un nuevo DN valor. Consulte Actualización progresiva de509 certificados X. que contienen un nuevo DN en clústeres autoadministrados.

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

A partir de MongoDB,4.4 mongod / registra una advertencia al conectarse si mongos el509 certificado X. presentado caduca dentro de los 30 días posteriores al mongod/mongos reloj del sistema. Utilice el parámetro para controlar el umbral de advertencia de caducidad del tlsX509ExpirationWarningThresholdDays 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

Por defecto: 30

Disponible solo para mongos.

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.

authFailedDelayMs

Por defecto: 0

Disponible tanto para mongod como para mongos.

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.

allowRolesFromX509Certificates

Por defecto: true

Disponible tanto para mongod como para mongos.

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.

Parámetros generales

allowDiskUseByDefault

Por defecto: true

Disponible solo para mongod.

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

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

connPoolMaxConnsPerHost

Por defecto: 200

Disponible tanto para mongod como para mongos.

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

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

cursorTimeoutMillis

Por defecto: 600000 (10 minutos)

Disponible tanto para mongod como para mongos.

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.

maxNumActiveUserIndexBuilds

Disponible solo para mongod.

Tipo: entero

Por defecto: 3

Establece el número máximo de compilaciones de índice simultáneas permitidas en el índice principal. Este límite global se aplica a todas las colecciones.

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:

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 consultas no indexadas notablescan sin, considere leer la sección Evaluar el rendimiento de las operaciones actuales y usar el logLevel parámetro, mongostat y la creación de perfiles.

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.

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 ejecute instancias de producciónmongodcon ttlMonitorEnabled deshabilitado, excepto bajo la supervisión del soporte de MongoDB. Impedir la eliminación de documentos TTL puede afectar negativamente las operaciones internas del sistema MongoDB que dependen de índices TTL.

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.

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

disableJavaScriptJIT

Disponible solo para mongod.

El motor JavaScript de MongoDB utiliza SpiderMonkey, que implementa la compilación Just-in-Time (JIT) para mejorar el rendimiento al ejecutar scripts.

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 habilitar el JIT, configure disableJavaScriptJIT falseen, como en el siguiente ejemplo:

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

Nota

$where reutilizará los contextos del intérprete de JavaScript existentes, por lo que los cambios en disableJavaScriptJIT pueden no tener efecto inmediatamente para estas operaciones.

Alternativamente, puede habilitar el JIT en el momento del inicio iniciando la mongod instancia con la siguiente opción:

mongod --setParameter disableJavaScriptJIT=false

indexMaxNumGeneratedKeysPerDocument

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.

maxIndexBuildMemoryUsageMegabytes

Por defecto: 200

Limita la cantidad de memoria que las compilaciones simultáneas de índices en una colección pueden consumir durante las compilaciones. La cantidad de memoria especificada se comparte entre todos los índices compilados mediante un único comando o su asistente createIndexes de db.collection.createIndexes() shell.

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.

La memoria consumida por la creación de un índice es independiente de la memoria caché de WiredTiger cacheSizeGB (consulte).

maxIndexBuildMemoryUsageMegabytes Establece un límite en la cantidad de memoria que la compilación del índice usa simultáneamente. Esto puede afectar el rendimiento al generar y ordenar las claves del índice. Aumentar el límite de memoria mejora el rendimiento de la ordenación durante la compilación del índice.

La creación de índices puede iniciarse mediante un comando de usuario, como "Crear índice", o mediante un proceso administrativo, como una sincronización inicial. Ambos están sujetos al límite establecido maxIndexBuildMemoryUsageMegabytes por.

Una operación de sincronización inicial rellena solo una colección a la vez y no existe riesgo de exceder el límite de memoria. Sin embargo, es posible que un usuario inicie compilaciones de índices en varias colecciones de varias bases de datos simultáneamente y potencialmente consuma una cantidad de memoria superior al límite establecido maxIndexBuildMemoryUsageMegabytes en.

Tip

Para minimizar el impacto de la creación de un índice en conjuntos de réplicas y clústeres fragmentados con fragmentos de conjuntos de réplicas, utilice un procedimiento de creación de índice continuo como se describe en Creaciones de índice continuo en conjuntos de réplicas.

Advertencia

Evita realizar procesos de creación de índices en modo continuo y replicado al mismo tiempo, ya que podría generar problemas inesperados, como compilaciones fallidas y bucles de fallos.

Cambiar maxIndexBuildMemoryUsageMegabytes no afecta la compilación de un índice en curso si ya se ha iniciado un análisis de colección. Sin embargo, una reconfiguración forzada del conjunto de réplicas reinicia el análisis de colección y utiliza el maxIndexBuildMemoryUsageMegabytes más reciente proporcionado.

Para la versión de compatibilidad de funciones (fcv) "4.2" y posteriores, el límite de memoria de compilación de índice se aplica a todas las compilaciones de índice.

reportOpWriteConcernCountersInServerStatus

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.

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 journal directorio dentro del --dbpath directorio si está journaling habilitado
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 se puede habilitar el Vigilante del Nodo de Almacenamiento al inicio. Sin embargo, una vez habilitado, se puede pausar o cambiar el durante watchdogPeriodSeconds la ejecución.

Una vez habilitado,

Para pausar el Watchdog del nodo de almacenamiento durante el tiempo de ejecución, configure watchdogPeriodSeconds en1 -.
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: -1 } )
```
Para reanudar o cambiar el período durante el tiempo de ejecución, establezca en un número mayor o watchdogPeriodSeconds igual 60 a.
```
db.adminCommand( { setParameter: 1, watchdogPeriodSeconds: 120 } )
```

Nota

Es un error configurar en watchdogPeriodSeconds tiempo de ejecución si el sistema de vigilancia del nodo de almacenamiento no estaba habilitado en el momento de inicio.

tcmallocAggressiveMemoryDecommit

Tipo: entero (solo0 1 o)

Por defecto: 0

Si habilita tcmallocAggressiveMemoryDecommit, MongoDB:

libera una porción de memoria al sistema y
intenta devolver todos los fragmentos libres vecinos.

Un valor de 1 habilita tcmallocAggressiveMemoryDecommit; 0 deshabilita este parámetro.

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 habilita este parámetro, el sistema requerirá nuevas asignaciones de memoria para su uso. Considere habilitar tcmallocAggressiveMemoryDecommit solo en sistemas con limitaciones de memoria y después de considerar otras opciones de memoria y rendimiento.

A pesar de la posible degradación del rendimiento al tcmallocAggressiveMemoryDecommit utilizar, a menudo se prefiere al uso tcmallocReleaseRate de.

tcmallocReleaseRate

Por defecto: 1.0

Especifica la tasa de liberación de tcmalloc(TCMALLOC_RELEASE_RATE). Según https://gperftools.github.io/gperftools/tcmalloc.html#runtime, TCMALLOC_RELEASE_RATE se describe como la "tasa a la que liberamos memoria no utilizada al sistema, mediante madvise(MADV_DONTNEED), en sistemas compatibles. Un valor cero significa que nunca liberamos memoria al sistema. Aumente este indicador para que la memoria se devuelva más rápido; redúzcalo para que se devuelva más lento. Las tasas razonables se encuentran en el rango0 [,]."10

Nota

Considere utilizar tcmallocAggressiveMemoryDecommit en lugar de, a menos que observe una degradación significativa del rendimiento tcmallocReleaseRate al tcmallocAggressiveMemoryDecommit utilizar.

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

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

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

mongod --setParameter "tcmallocReleaseRate=5.0"

fassertOnLockTimeoutForStepUpDown

Novedades en la versión 5.3.

Por defecto: 15 segundos

Disponible tanto para mongod como para mongos.

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

Parámetros de registro

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. [2]

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

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

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. [3]

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:

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.

[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

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

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

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

Nota

Los valores por defecto para el intervalo de captura de datos de diagnóstico y los tamaños máximos se eligen para proporcionar datos útiles a los ingenieros de MongoDB con un impacto mínimo en el rendimiento y en el tamaño de almacenamiento. Normalmente, estos valores solo necesitarán modificaciones a petición de los ingenieros de MongoDB para fines de diagnóstico específicos.

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

diagnosticDataCollectionDirectoryPath

Tipo: string

Disponible solo para mongos.

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: 200

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.

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.

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

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

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

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

Para permitir cambios de configuración mediante direcciones IP, configure disableSplitHorizonIPCheck=true utilizando el archivo de configuración del nodo:

setParameter:
   disableSplitHorizonIPCheck: true

Si intenta actualizar disableSplitHorizonIPCheck en tiempodb.adminCommand() de ejecución, devuelve un error:

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

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

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

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

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

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

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

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.

Aumentar oplogBatchDelayMillis hace que MongoDB aplique lotes de registros de operaciones con menos frecuencia en los secundarios, y cada lote contiene mayores cantidades de datos. Esto reduce IOPS en secundarias, pero agrega latencia para escrituras con preocupación de "majority" escritura.

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

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

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'

storeFindAndModifyImagesInSideCollection

Nuevo en la versión 5.0.

Disponible tanto para mongod como para mongos.

Tipo: booleano

Por defecto: true

Determina si los documentos temporales necesarios para los comandos reintentables se findAndModify almacenan en la colección lateral config.image_collection ().

Si storeFindAndModifyImagesInSideCollection es:

true, los documentos temporales se almacenan en la colección lateral.
falseLos documentos temporales se almacenan en el registro de operaciones del conjunto de réplicas.

Mantenga storeFindAndModifyImagesInSideCollection establecido en true si usted:

Tiene una gran carga de findAndModify trabajo reintentable.
Se requiere más espacio de documento temporal para comandos que se puedan volver a intentar que el que está disponible en el registro de operaciones findAndModify del conjunto de réplicas.

Nota

Los secundarios pueden experimentar un mayor uso de CPU storeFindAndModifyImagesInSideCollection cuando true es.

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 storeFindAndModifyImagesInSideCollection en false durante el inicio:

mongod --setParameter storeFindAndModifyImagesInSideCollection=false

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

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

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

enableFlowControl

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.

flowControlTargetLagSeconds

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

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.

initialSyncTransientErrorRetryPeriodSeconds

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.

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.

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.

maxNumSyncSourceChangesPerHour

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.

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

Tipo: entero

Por defecto: 60

Disponible solo para mongod.

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.

replWriterThreadCount

Tipo: entero

Por defecto: 16

Disponible solo para mongod.

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

replWriterMinThreadCount

Nuevo en la versión 5.0.

Tipo: entero

Por defecto: 0

Disponible solo para mongod.

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.

rollbackTimeLimitSecs

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.

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

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.

replBatchLimitBytes

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

mirrorReads

Disponible solo para mongod.

Nuevo en la versión 4.4.

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.

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

allowMultipleArbiters

Disponible solo para mongod.

Novedades en la versión 5.3.

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

Parámetros de partición

balancerMigrationsThrottlingMs

Novedades en la 6.0.6 versión: (Tambiéndisponible a partir de 5.0.18 la)

Tipo: entero

Por defecto: 1000

Disponible solo para mongod.

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

chunkDefragmentationThrottlingMS

Novedades en la versión 5.3.

Tipo: entero

Por defecto: 0

Disponible tanto para mongod como para mongos.

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

disableResumableRangeDeleter

Disponible solo para mongod.

Tipo: booleano

Por defecto: false

Si se configura en el principal de un fragmento, especifica si se pausa la eliminación de rangos en el fragmento. Si se configura true en, se pausa la limpieza de los rangos de fragmentos que contienen documentos huérfanos. El fragmento puede seguir donando fragmentos a otros fragmentos, pero los documentos donados no se eliminarán de este fragmento hasta que se configure este parámetro false en. Este fragmento puede seguir recibiendo fragmentos de otros fragmentos siempre que no tenga una tarea de eliminación de rango pendiente en la config.rangeDeletions colección 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.

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

mongod --setParameter disableResumableRangeDeleter=false

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.

opportunisticSecondaryTargeting

Nuevo en la versión 6.0.0.

Tipo: booleano

Por defecto: false

Disponible solo para mongos.

Determina si mongos realiza lecturas oportunistas en conjuntos de réplicas.

Cuando este parámetro se establece true en, dirige las lecturas secundarias a los secundarios con conexiones activas. Envía la solicitud al primer secundario que acepta la conexión. Cuando este parámetro semongos establece false en, mongos retiene las lecturas secundarias hasta que puede establecer una conexión con un secundario específico (excepto en el caso de lecturas protegidas).

Nota

Bajo ciertas cargas de trabajo, las lecturas oportunistas pueden provocar la apertura de conexiones innecesarias de mongos a y reducir mongod el rendimiento general. Este parámetro no debe habilitarse a menos que su aplicación necesite específicamente esta funció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.

Por ejemplo, para establecer opportunisticSecondaryTargeting durante el inicio:

mongos --setParameter opportunisticSecondaryTargeting=true

shardedIndexConsistencyCheckIntervalMS

Disponible solo para mongod.

Tipo: entero

Por defecto: 600000

Si se establece en el primario del servidor de configuración, el intervalo, en milisegundos, en el que el primario del servidor de configuración verifica la coherencia del índice de las colecciones fragmentadas. El parámetro no tiene efecto en el mongod si no es el servidor de configuración primario.

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

Por ejemplo, lo siguiente establece el intervalo en 300 000 milisegundos (5 minutos) durante la iniciación:

mongod --setParameter shardedIndexConsistencyCheckIntervalMS=300000

Tip

enableShardedIndexConsistencyCheck parameter
shardedIndexConsistency métricas devueltas por el comando serverStatus

enableFinerGrainedCatalogCacheRefresh

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

maxTimeMSForHedgedReads

Disponible solo para mongos.

Tipo: entero

Por defecto: 150

Especifica el límite de tiempo máximo (en milisegundos) para la lectura protegida. Es decir, la lectura adicional enviada para proteger la operación de lectura utiliza el maxTimeMS valor de,maxTimeMSForHedgedReads mientras que la operación de lectura protegida utiliza el maxTimeMS valor especificado para la operació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.

Por ejemplo, para establecer el límite en 200 milisegundos, puede emitir lo siguiente durante el inicio:

mongos --setParameter maxTimeMSForHedgedReads=200

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

Tip

maxCatchUpPercentageBeforeBlockingWrites

Nuevo en la versión 5.0.

Disponible solo para mongod.

Tipo: entero

Por defecto: 10

Para las operaciones de moveChunk y moveRange, se especifica el porcentaje máximo de datos no transferidos permitido por el protocolo de migración (expresado como porcentaje del tamaño total del fragmento) para que pase de la fase catchup a la fase commit.

Establecer un porcentaje de recuperación más alto puede reducir el tiempo necesario para completar la migración, con un costo de un aumento de la latencia durante las operaciones concurrentes de upsert y delete.

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

Cambiado en la 7.1 versión:7.0.1 (y), puede configurar el parámetro durante el tiempo de ejecución.

Por ejemplo, para establecer el porcentaje máximo en 20, puedes emitir lo siguiente durante la iniciación:

mongod --setParameter maxCatchUpPercentageBeforeBlockingWrites=20

No se puede cambiar durante el tiempo de maxCatchUpPercentageBeforeBlockingWrites ejecución.

Tip

Protocolo de migración en vivo

metadataRefreshInTransactionMaxWaitBehindCritSecMS

Nuevo en la versión 5.2: (También disponible a partir de las versiones 5.1.0, 5.0.4)

Tipo: entero

Por defecto: 500

Disponible solo para mongod.

Limita el tiempo que un fragmento espera para una sección crítica dentro de una transacción.

Cuando una query accede a un fragmento, una migración de fragmento o una operación DDL ya puede retener la sección crítica de la colección. Si la query encuentra que la sección crítica está ocupada, el fragmento espera hasta que se libere la sección crítica. Cuando el fragmento devuelve el control a mongos, mongos intenta de nuevo la query. Sin embargo, si una transacción de múltiples fragmentos interactúa con una operación que toma la sección crítica en varios fragmentos, la interacción puede ocasionar un interbloqueo distribuido.

metadataRefreshInTransactionMaxWaitBehindCritSecMS limita el tiempo máximo que un fragmento espera dentro de una transacción para que se libere la sección crítica.

Para reducir el tiempo máximo de espera de la sección crítica dentro de una transacción, reduce el valor de metadataRefreshInTransactionMaxWaitBehindCritSecMS.

Advertencia

Si metadataRefreshInTransactionMaxWaitBehindCritSecMS es demasiado bajo, mongos podría utilizar todos sus intentos de reintento y devolver un error.

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 configurar metadataRefreshInTransactionMaxWaitBehindCritSecMS a 400 milisegundos:

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

readHedgingMode

Disponible solo para mongos.

Tipo: string

Predeterminado: activado

Especifica si admite lecturas cubiertas mongos para aquellas operaciones de lectura cuya preferencia de lectura ha habilitado la opción de lectura cubierta.

Los valores disponibles son:

Valor	Descripción
`on`	La instancia admite lecturas `mongos` cubiertas para operaciones de lectura cuya preferencia de lectura haya habilitado la opción de lectura cubierta.
`off`	La instancia no admite lecturas protegidas. Es decir, no están disponibles, ni siquiera para operaciones de lectura cuya preferencia de lectura la tenga `mongos` habilitada.

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 desactivar la compatibilidad de lectura protegida para una mongos instancia, puede emitir lo siguiente durante el inicio:

mongos --setParameter readHedgingMode=off

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

Tip

routingTableCacheChunkBucketSize

Nuevo en la versión 6.0.10.

Disponible tanto para mongod como para mongos.

Tipo: entero

Por defecto: 500

Especifica el tamaño de los compartimentos de caché de la tabla de enrutamiento utilizados para implementar la optimización de agrupación de fragmentos. Debe ser mayor que 0.

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

Por ejemplo, para configurar el tamaño del bucket de fragmento de caché a 250 en un mongod, emita el siguiente comando durante la iniciación:

mongod --setParameter routingTableCacheChunkBucketSize=1000

shutdownTimeoutMillisForSignaledShutdown

Nuevo en la versión 5.0.

Tipo: entero

Por defecto: 15000

Disponible solo para mongod.

Especifica el tiempo (en milisegundos) que se debe esperar a que se completen las operaciones de base de datos en curso antes de iniciar un apagado de mongod en respuesta a una señal de SIGTERM.

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 ajustar el tiempo a 250 milisegundos, puedes emitir lo siguiente durante la iniciación:

mongod --setParameter shutdownTimeoutMillisForSignaledShutdown=250

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongod en ejecución:

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

mongosShutdownTimeoutMillisForSignaledShutdown

Nuevo en la versión 5.0.

Tipo: entero

Por defecto: 15000

Disponible solo para mongos.

Especifica el tiempo (en milisegundos) que se debe esperar a que se completen las operaciones de base de datos en curso antes de iniciar un apagado de mongos en respuesta a una señal de SIGTERM.

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 ajustar el tiempo a 250 milisegundos, puedes emitir lo siguiente durante la iniciación:

mongos --setParameter mongosShutdownTimeoutMillisForSignaledShutdown=250

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

ShardingTaskExecutorPoolHostTimeoutMS

Tipo: entero

Valor por defecto: 300000 (5 minutos)

Disponible tanto para mongod como para mongos.

Tiempo máximo que mongos puede estar sin comunicación con un host antes de que mongos descarte todas las conexiones con el host.

Si se establece, ShardingTaskExecutorPoolHostTimeoutMS debe ser mayor que la suma de ShardingTaskExecutorPoolRefreshRequirementMS y ShardingTaskExecutorPoolRefreshTimeoutMS. De lo contrario, mongos ajusta el valor de ShardingTaskExecutorPoolHostTimeoutMS para que sea mayor que la suma.

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 ShardingTaskExecutorPoolHostTimeoutMS a 120000 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolHostTimeoutMS=120000

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

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

ShardingTaskExecutorPoolMaxConnecting

Tipo: entero

Por defecto: 2

Disponible tanto para mongod como para mongos.

Número máximo de conexiones iniciadoras simultáneas (incluidas las conexiones pendientes en estado de configuración/actualización) que cada pool de conexiones de TaskExecutor puede tener con una instancia de mongod. Puedes establecer este parámetro para controlar la velocidad a la que mongos agrega conexiones a una instancia de mongod.

Si se establece, ShardingTaskExecutorPoolMaxConnecting debe ser menor o igual que ShardingTaskExecutorPoolMaxSize. Si es mayor, mongos ignora el valor de ShardingTaskExecutorPoolMaxConnecting.

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 ShardingTaskExecutorPoolMaxConnecting a 20 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolMaxConnecting=20

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

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

ShardingTaskExecutorPoolMaxSize

Tipo: entero

Por defecto: 2 ⁶⁴ - 1

Disponible tanto para mongod como para mongos.

Número máximo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a cualquier instancia de mongod dada. El número máximo posible de conexiones a cualquier host dado en todos los pools de TaskExecutor es:

ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize

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 ShardingTaskExecutorPoolMaxSize a 20 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolMaxSize=20

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

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

mongos puede tener hasta n pools de conexiones de TaskExecutor, donde n es la cantidad de núcleos. Consulte taskExecutorPoolSize.

Tip

ShardingTaskExecutorPoolMinSize

ShardingTaskExecutorPoolMaxSizeForConfigServers

Novedades en la versión 6.0.

Tipo: entero

Por defecto: -1

Disponible tanto para mongod como para mongos.

Anulación opcional para ShardingTaskExecutorPoolMaxSize para establecer el número máximo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración.

Cuando se establece en:

-1, ShardingTaskExecutorPoolMaxSize se utiliza. Este es el valor por defecto.
un valor entero mayor que -1, sobrescribe el número máximo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración.

El parámetro solo se aplica a las implementaciones fragmentadas.

El siguiente ejemplo configura ShardingTaskExecutorPoolMaxSize a 2 durante el inicio, lo que establece la cantidad máxima de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración en 2:

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

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

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

ShardingTaskExecutorPoolMinSize

Tipo: entero

Por defecto: 1

Disponible tanto para mongod como para mongos.

Número mínimo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a cualquier instancia mongod.

ShardingTaskExecutorPoolMinSize Las conexiones se crean la primera vez que se solicita una conexión a un nuevo host desde el grupo. Mientras el pool está inactivo, mantiene esta cantidad de conexiones hasta que pasen ShardingTaskExecutorPoolHostTimeoutMS milisegundos sin que ninguna aplicación utilice ese pool.

Para una mongos que utiliza el parámetro warmMinConnectionsInShardingTaskExecutorPoolOnStartup, el parámetro ShardingTaskExecutorPoolMinSize también controla cuántas conexiones a cada host de partición se establecen al iniciar la instancia de mongos antes de que comience a aceptar conexiones entrantes de clientes.

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 ShardingTaskExecutorPoolMinSize a 2 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolMinSize=2

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

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

mongos puede tener hasta n pools de conexiones de TaskExecutor, donde n es la cantidad de núcleos. Consulte taskExecutorPoolSize.

Tip

ShardingTaskExecutorPoolMaxSize
warmMinConnectionsInShardingTaskExecutorPoolOnStartup

ShardingTaskExecutorPoolMinSizeForConfigServers

Novedades en la versión 6.0.

Tipo: entero

Por defecto: -1

Disponible tanto para mongod como para mongos.

Anulación opcional para ShardingTaskExecutorPoolMinSize para establecer el número mínimo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración.

Cuando se establece en:

-1, ShardingTaskExecutorPoolMinSize se utiliza. Este es el valor por defecto.
un valor entero mayor que -1 anula la cantidad mínima de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración.

El parámetro solo se aplica a las implementaciones fragmentadas.

El siguiente ejemplo configura ShardingTaskExecutorPoolMinSize a 2 durante el inicio, lo que establece el número mínimo de conexiones salientes que cada pool de conexiones de TaskExecutor puede abrir a un servidor de configuración en 2:

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

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

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

ShardingTaskExecutorPoolRefreshRequirementMS

Tipo: entero

Por defecto: 60000 (1 minuto)

Disponible tanto para mongod como para mongos.

Tiempo máximo que el mongos espera antes de intentar enviar un latido a una conexión inactiva en el grupo. Una conexión inactiva puede ser descartada durante la actualización si el grupo está por encima de su tamaño mínimo.

Si se establece, ShardingTaskExecutorPoolRefreshRequirementMS debería ser mayor que ShardingTaskExecutorPoolRefreshTimeoutMS. De lo contrario, mongos ajustará el valor de ShardingTaskExecutorPoolRefreshTimeoutMS para que sea menor que ShardingTaskExecutorPoolRefreshRequirementMS.

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 ShardingTaskExecutorPoolRefreshRequirementMS a 90000 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolRefreshRequirementMS=90000

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

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

ShardingTaskExecutorPoolRefreshTimeoutMS

Tipo: entero

Por defecto: 20000 (20 segundos)

Disponible tanto para mongod como para mongos.

Tiempo máximo que el mongos espera una señal de latido antes de que se agote su tiempo de espera.

Si se establece, ShardingTaskExecutorPoolRefreshTimeoutMS debería ser menor que ShardingTaskExecutorPoolRefreshRequirementMS. De lo contrario, mongos ajusta el valor de ShardingTaskExecutorPoolRefreshTimeoutMS para que sea menor que ShardingTaskExecutorPoolRefreshRequirementMS.

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 ShardingTaskExecutorPoolRefreshTimeoutMS a 30000 durante el inicio:

mongos --setParameter ShardingTaskExecutorPoolRefreshTimeoutMS=30000

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

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

ShardingTaskExecutorPoolReplicaSetMatching

Modificado en la versión 5.0.

Disponible tanto para mongod como para mongos.

Tipo: string

Por defecto: "automático"

En una instancia mongos, este parámetro establece la política que determina el límite de tamaño mínimo de sus pools de conexiones a nodos dentro de los sets de réplicas.

En una instancia mongod, este parámetro establece la política que determina el límite de tamaño mínimo de sus pools de conexiones a nodos dentro de otros sets de réplicas.

Ten en cuenta que este parámetro solo gestiona las conexiones para operaciones directamente relacionadas con las solicitudes de los usuarios y las operaciones CRUD.

Los valores disponibles son:

Política de coincidencia	Descripción
`"automatic"` (por defecto)	A partir de 5.0, `"automatic"` es el nuevo valor por defecto. Cuando se configura para un `mongos`, la instancia sigue el comportamiento especificado para la opción `"matchPrimaryNode"`. Cuando se configura para un `mongod`, la instancia sigue el comportamiento especificado para la opción `"disabled"`. ADVERTENCIA: Si el `ShardingTaskExecutorPoolReplicaSetMatching` está configurado en `"automatic"`, el `replicaSetMatchingStrategy` sigue describiendo la política real que se está utilizando, no `"automatic"`. Para encontrar el valor del `ShardingTaskExecutorPoolReplicaSetMatching`, utiliza `getParameter` que devuelve el valor del parámetro del servidor.
`"matchPrimaryNode"`	Cuando se configura para un `mongos`, el límite de tamaño mínimo del pool de conexiones de la instancia a cada secundario de un set de réplicas en el clúster (específicamente, set de réplicas de fragmentos y servidores de configuración) es igual al tamaño de su pool de conexiones al primario de ese set de réplicas. Cuando se configura para un `mongod`, el límite de tamaño mínimo del pool de conexiones de la instancia a cada secundario de otro set de réplicas en el clúster (específicamente, set de réplicas de fragmento y servidores de configuración) es igual al tamaño de su pool de conexiones con el primario de ese set de réplicas. ADVERTENCIA: Si varios servidores de partición en su topología pueden experimentar una rápida afluencia de operaciones entre fragmentos, no configure esta opción en sus instancias de `mongod`. En caso de una degradación del primario, `matchPrimaryNode` asegura que cualquier secundario que se convierta en primario pueda gestionar el nivel actual de lecturas y escrituras del primario.
`"matchBusiestNode"`	Cuando se configura para un `mongos`, el límite de tamaño mínimo del pool de conexiones de la instancia a cada nodo de un set de réplicas en el clúster (específicamente, el set de réplicas de fragmento y los servidores de configuración) es igual al mayor entre los recuentos de conexiones activas al primario y a cada nodo secundario de ese set de réplicas. Cuando se configura para un `mongod`, el límite de tamaño mínimo del pool de conexiones de la instancia a cada miembro de otro set de réplicas en el clúster (específicamente, el set de réplicas de fragmento y los servidores de configuración) es igual al mayor entre los recuentos de conexiones activas al primario y a cada secundario de ese set de réplicas. Con `"matchBusiestNode"`, `mongos` mantiene suficientes conexiones con cada secundario para gestionar el nivel actual de lecturas y escrituras de primarios y secundarios. El número de conexiones que se deben mantener en el pool disminuye a medida que disminuye el número de conexiones activas.
`"disabled"`	Cuando se establece para un `mongos`, la cantidad mínima de conexiones de la instancia en el pool de conexiones de la instancia a cada nodo de un set de réplicas en el clúster particionado (específicamente, el set de réplicas de fragmento y los servidores de configuración) es igual al `ShardingTaskExecutorPoolMinSize`. Cuando se configura para un `mongod`, la cantidad mínima de conexiones de la instancia en el pool de conexiones de la instancia a cada nodo de otro set de réplicas en el clúster particionado (específicamente, el set de réplicas de fragmentos y los servidores de configuración) es igual al `ShardingTaskExecutorPoolMinSize`.

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 ShardingTaskExecutorPoolReplicaSetMatching a "automatic" durante el inicio:

mongod --setParameter ShardingTaskExecutorPoolReplicaSetMatching="automatic"

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

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

taskExecutorPoolSize

Tipo: entero

Por defecto: 1

Disponible solo para mongos.

El número de pools de conexiones del TaskExecutor que se usará para un mongosdado.

Si el valor del parámetro es 0 o menos, el número de pools de conexiones del TaskExecutor es igual al número de núcleos, con las siguientes excepciones:

Si el número de núcleos es inferior a 4, el número de pools de conexiones del TaskExecutor es 4.
Si el número de núcleos es mayor que 64, el número de pools de conexión del TaskExecutor es 64.

Importante

Antes de modificar el taskExecutorPoolSize valor en Linux, consulte con un profesional de soporte de MongoDB. Modificar este parámetro puede causar regresiones en el rendimiento.

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

Tip

ShardingTaskExecutorPoolMaxSize
ShardingTaskExecutorPoolMinSize

loadRoutingTableOnStartup

Disponible solo para mongos.

Tipo: booleano

Por defecto: true

Configura una instancia mongos para precargar la tabla de enrutamiento de un clúster fragmentado durante la iniciación. Con esta configuración habilitada, el mongos almacena en caché la tabla de enrutamiento de todo el clúster para cada colección fragmentada como parte de su procedimiento de iniciación, antes de comenzar a aceptar conexiones de clientes.

Sin esta configuración habilitada, el mongos solo carga una tabla de enrutamiento cuando es necesario para las conexiones de clientes entrantes, y solo carga la tabla de enrutamiento específica para el namespace de una solicitud dada.

Una instancia de mongos con el parámetro loadRoutingTableOnStartup habilitado puede experimentar tiempos de inicio más largos, pero resultará en un servicio más rápido de las conexiones iniciales de los clientes una vez iniciadas.

loadRoutingTableOnStartup está activado por defecto.

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

warmMinConnectionsInShardingTaskExecutorPoolOnStartup

Disponible solo para mongos.

Tipo: booleano

Por defecto: true

Configura una instancia mongos para precalentar su pool de conexiones durante la iniciación. Con este parámetro habilitado, el mongos intenta establecer conexiones de red ShardingTaskExecutorPoolMinSize con cada servidor de particiones como parte de su procedimiento de iniciación, antes de comenzar a aceptar conexiones de clientes.

Se puede configurar un tiempo de espera para este comportamiento con el parámetro warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS. Si se alcanza este tiempo de espera, el mongos comenzará a aceptar conexiones de clientes independientemente del tamaño de su pool de conexiones.

Una instancia mongos con este parámetro habilitado puede experimentar tiempos de iniciación más largos, pero dará como resultado un servicio más rápido de las conexiones iniciales de los clientes una vez iniciadas.

warmMinConnectionsInShardingTaskExecutorPoolOnStartup está activado por defecto.

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

Tip

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS
ShardingTaskExecutorPoolMinSize

warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS

Disponible solo para mongos.

Tipo: entero

Por defecto: 2000 (2 segundos)

Establece el umbral de tiempo de espera en milisegundos para que un mongos espere a que se establezcan conexiones ShardingTaskExecutorPoolMinSize por host de fragmento cuando se utiliza el parámetro warmMinConnectionsInShardingTaskExecutorPoolOnStartup. Si se alcanza este tiempo de espera, el mongos comenzará a aceptar conexiones de clientes independientemente del tamaño de su pool de conexiones.

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

Tip

warmMinConnectionsInShardingTaskExecutorPoolOnStartup
ShardingTaskExecutorPoolMinSize

migrateCloneInsertionBatchDelayMS

Disponible solo para mongod.

Tipo: entero no negativo

Por defecto: 0

Tiempo en milisegundos para esperar entre agrupaciones de inserciones durante el paso de clonación del proceso de migración. Esta espera es adicional al secondaryThrottle.

El valor por defecto de 0 indica que no hay espera adicional.

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.

Lo siguiente configura el migrateCloneInsertionBatchDelayMS a 200 milisegundos:

mongod --setParameter migrateCloneInsertionBatchDelayMS=200

El parámetro también puede configurarse con el comando setParameter:

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

migrateCloneInsertionBatchSize

Disponible solo para mongod.

Tipo: entero no negativo

Por defecto: 0

El número máximo de documentos que se pueden insertar en una sola agrupación durante la etapa de clonación del proceso de migración.

El valor por defecto de 0 indica que no hay un número máximo de documentos por agrupación. Sin embargo, en la práctica, esto da lugar a agrupaciones que contienen hasta 16 MB de documentos.

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.

Lo siguiente configura el migrateCloneInsertionBatchSize a 100 documentos:

mongod --setParameter migrateCloneInsertionBatchSize=100

El parámetro también puede configurarse con el comando setParameter:

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

orphanCleanupDelaySecs

Por defecto: 900 (15 minutos)

Disponible solo para mongod.

Demora mínima antes de que un fragmento migrado se elimine del fragmento de origen.

Antes de eliminar el fragmento durante la migración del fragmento, MongoDB espera o que las consultas en curso que involucran el fragmento se completen en el fragmento principal, lo que sea más orphanCleanupDelaySecs largo.

Sin embargo, debido a que el fragmento principal no tiene conocimiento de las consultas en curso que se ejecutan en los fragmentos secundarios, las consultas que usan el fragmento pero se ejecutan en los secundarios pueden hacer que desaparezcan los documentos si estas consultas tardan más que el tiempo necesario para completar las consultas del fragmento principal y orphanCleanupDelaySecs el.

Nota

Este comportamiento solo afecta a las consultas en curso que se inician antes de la migración del fragmento. Las consultas que se inician después de la migración del fragmento no utilizarán el fragmento en migración.

Si una partición tiene restricciones de almacenamiento, considere reducir este valor de forma temporal. Si ejecuta queries que superan los 15 minutos en secundarios de particiones, considere aumentar este valor.

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.

Lo siguiente configura el orphanCleanupDelaySecs a 20 minutos:

mongod --setParameter orphanCleanupDelaySecs=1200

Esto también puede configurarse usando el comando setParameter:

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

persistedChunkCacheUpdateMaxBatchSize

Novedades en la 6.0.13 versión:5.0.25 (y)

Disponible solo para mongod.

Tipo: entero

Por defecto: 1000

Para enrutar y servir operaciones, los fragmentos deben conocer la información de enrutamiento y propiedad asociada a sus colecciones. Esta información se propaga desde el nodo principal de un fragmento a sus nodos secundarios mediante la replicación de las colecciones de caché interna config.cache.collections y config.cache.chunks.<collectionName>.

En versiones anteriores, las actualizaciones de la colección de caché de fragmentos se realizaban individualmente (es decir, se eliminaba una entrada y se insertaba una nueva). A partir de MongoDB 6.0.13, estas actualizaciones se realizan como un lote de eliminaciones seguido de un lote de inserciones. La lógica actualizada mejora el rendimiento de las colecciones que contienen una gran cantidad de fragmentos.

El parámetro persistedChunkCacheUpdateMaxBatchSize especifica el tamaño máximo de agrupación utilizado para actualizar la caché de fragmentos persistida.

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 persistedChunkCacheUpdateMaxBatchSize en 700 durante la iniciación:

mongod --setParameter persistedChunkCacheUpdateMaxBatchSize=700

También puede configurar persistedChunkCacheUpdateMaxBatchSize durante la ejecución:

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

rangeDeleterBatchDelayMS

Disponible solo para mongod.

Tipo: entero no negativo

Por defecto: 20

La cantidad de tiempo en milisegundos que se debe esperar antes del siguiente lote de eliminación durante la etapa de limpieza de la migración de rango (o el cleanupOrphaned comando).

La demora de replicación de _secondaryThrottle ocurre después de cada eliminación por grupos.

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.

Lo siguiente configura el rangeDeleterBatchDelayMS a 200 milisegundos:

mongod --setParameter rangeDeleterBatchDelayMS=200

El parámetro también puede configurarse con el comando setParameter:

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

rangeDeleterBatchSize

Disponible solo para mongod.

Tipo: entero no negativo

Por defecto: 2147483647 a partir de MongoDB 5.1.2 y 5.0.6

La cantidad máxima de documentos en cada lote que se eliminarán durante la etapa de limpieza de la migración de rango (o el cleanupOrphaned comando).

Un valor de 0 indica que el sistema elige el valor 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.

El siguiente ejemplo configura rangeDeleterBatchSize para 32 documentos:

mongod --setParameter rangeDeleterBatchSize=32

El parámetro también puede configurarse con el comando setParameter:

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

Tip

En versiones anteriores a 6.0.3, el nuevo valor de rangeDeleterBatchSize solo se aplica a las eliminaciones de rango creadas después de que se haya cambiado el valor. Para aplicar el nuevo valor a las eliminaciones de rangos existentes, fuerce un paso hacia abajo.

A partir de la versión 6.0.3, el nuevo valor del parámetro se aplica a todas las eliminaciones de rango procesadas después de la actualización, independientemente de cuándo se haya creado la eliminación de rango.

skipShardingConfigurationChecks

Disponible solo para mongod.

Tipo: booleano

Por defecto: false

Cuando true, permite iniciar un Nodo del fragmento o un Nodo del servidor de configuración como autónomo para operaciones de mantenimiento. Este parámetro es mutuamente excluyente con las opciones --configsvr o --shardsvr.

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

mongod --setParameter skipShardingConfigurationChecks=true

Importante

Una vez que se haya completado el mantenimiento, remueva el parámetro skipShardingConfigurationChecks al reiniciar el mongod.

findChunksOnConfigTimeoutMS

Nuevo en la versión 5.0.

Disponible tanto para mongod como para mongos.

Tipo: entero no negativo

Por defecto: 900000

El tiempo de espera en milisegundos para las operaciones de búsqueda en chunks.

Si hay un gran número de fragmentos en el clúster y la carga de fragmentos falla con el error ExceededTimeLimit, aumente el valor del parámetro:

mongod --setParameter findChunksOnConfigTimeoutMS=1000000

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 del gestor de verificaciones de estado

activeFaultDurationSecs

Tipo: documento

Disponible solo para mongos.

El tiempo de espera desde una falla en la descripción general de gestores de verificaciones de estado hasta que el mongos se elimine del clúster, en segundos.

Cuando se detecta una falla y el gestor de verificaciones de estado está configurado como critical, el servidor espera el intervalo especificado antes de remover el mongos del clúster.

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 la duración desde la falla hasta la caída del sistema en cinco minutos, emite lo siguiente durante la iniciación:

mongos --setParameter activeFaultDurationSecs=300

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

Los parámetros establecidos con setParameter no persisten después de reiniciar. Consulte la página setParameter para más detalles.

Para que esta configuración sea persistente, se debe establecer activeFaultDurationSecs en el archivo de configuración de mongos con la opción setParameter como en el siguiente ejemplo:

setParameter:
   activeFaultDurationSecs: 300

healthMonitoringIntensities

Tipo: arreglo de documentos

Disponible solo para mongos.

Utilice este parámetro para establecer los niveles de intensidad para los gestores de verificaciones de estado.

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.

healthMonitoringIntensities acepta un arreglo de documentos, values. Cada documento en values requiere dos campos:

type, la faceta de gestión de verificaciónes de estado
intensity, el nivel de intensidad

Gestores de verificaciones de estado

Facet	Qué verifica el Health Observer
`configServer`	Problemas de salud del clúster relacionados con la conectividad al servidor de configuración.
`dns`	Problemas de salud del clúster relacionados con la disponibilidad y funcionalidad del DNS.
`ldap`	Problemas de salud del clúster relacionados con la disponibilidad y funcionalidad de LDAP.

Niveles de intensidad

Nivel de intensidad	Descripción
`critical`	El gestor de verificaciones de estado en esta faceta está habilitado y tiene la capacidad de mover los mongos que fallan fuera del clúster si ocurre un error. El gestor de verificaciones de estado espera el tiempo especificado por `activeFaultDurationSecs` antes de detenerse y mover el mongos fuera del clúster automáticamente.
`non-critical`	El gestor de verificaciones de estado en esta faceta está habilitado y registra errores, pero el mongos permanece en el clúster si se encuentran errores.
`off`	El gestor de verificaciones de estado en esta faceta está deshabilitado. El mongos no realiza ninguna verificación de estado en esta faceta. Este es el nivel de intensidad por defecto.

Por ejemplo, para establecer la faceta de gestión de verificaciones de estado dns al nivel de intensidad critical, emita lo siguiente al inicio:

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

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

Los parámetros establecidos con setParameter no persisten después de reiniciar. Consulte la página setParameter para más detalles.

Para que esta configuración sea persistente, se debe establecer healthMonitoringIntensities en el archivo de configuración de mongos con la opción setParameter como en el siguiente ejemplo:

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

healthMonitoringIntervals

Tipo: arreglo de documentos

Disponible solo para mongos.

Con qué frecuencia se ejecutará este gestor de verificaciones de estado, en milisegundos.

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.

healthMonitoringIntervals acepta un arreglo de documentos, values. Cada documento en values requiere dos campos:

type, la faceta de gestión de verificaciónes de estado
interval, el intervalo de tiempo en el que se ejecuta, en milisegundos

Gestores de verificaciones de estado

Facet	Qué verifica el Health Observer
`configServer`	Problemas de salud del clúster relacionados con la conectividad al servidor de configuración.
`dns`	Problemas de salud del clúster relacionados con la disponibilidad y funcionalidad del DNS.
`ldap`	Problemas de salud del clúster relacionados con la disponibilidad y funcionalidad de LDAP.

Por ejemplo, para configurar la faceta de gestión de verificaciones de estado ldap para ejecutar verificaciones de estado cada 30 segundos, emita lo siguiente al inicio.

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

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

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

Los parámetros establecidos con setParameter no persisten después de reiniciar. Consulte la página setParameter para más detalles.

Para que esta configuración sea persistente, se debe establecer healthMonitoringIntervals en el archivo de configuración de mongos con la opción setParameter como en el siguiente ejemplo:

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

progressMonitor

Tipo: documento

Disponible solo para mongos.

La supervisión del progreso ejecuta pruebas para garantizar que las comprobaciones del gestor de verificaciones de estado no se atascan ni dejan de responder. La supervisión del progreso ejecuta estas pruebas en los intervalos especificados por interval. Si una verificación de estado comienza pero no se completa dentro del tiempo de espera proporcionado por deadline, la supervisión del progreso detiene el mongos y lo elimina del clúster.

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.

`progressMonitor` Campos

Campo	Descripción	Unidades
`interval`	Con qué frecuencia se garantiza que los gestores de verificaciones de estado no se atasquen o dejen de responder.	Milisegundos
`deadline`	Tiempo de espera antes de fallar automáticamente el mongos si una verificación del gestor de verificaciones de estado no está progresando.	Segundos

Para establecer interval en 1000 milisegundos y deadline en 300 segundos, emite lo siguiente durante la iniciación:

mongos --setParameter 'progressMonitor={"interval": 1000, "deadline": 300}'

O si usas el comando setParameter en una sesión de mongosh que está conectada a un mongos en ejecución:

db.adminCommand(
  {
      setParameter: 1,
      progressMonitor: { interval: 1000, deadline: 300 } )
  }
)

Los parámetros establecidos con setParameter no persisten después de reiniciar. Consulte la página setParameter para más detalles.

Para que esta configuración sea persistente, se debe establecer progressMonitor en el archivo de configuración de mongos con la opción setParameter como en el siguiente ejemplo:

setParameter:
   progressMonitor: "{ interval: 1000, deadline: 300 }"

Parámetros de almacenamiento

honorSystemUmask

Disponible solo para mongod.

Por defecto: false

Si honorSystemUmask se establece en true, los archivos nuevos creados por MongoDB tienen permisos de acuerdo con la configuración umask del usuario. No puedes establecer processUmask si honorSystemUmask está configurado en true.

Si honorSystemUmask se establece en false, los nuevos archivos creados por MongoDB tienen permisos establecidos en 600, lo que otorga permisos de lectura y escritura solo al propietario. Los nuevos directorios tienen permisos establecidos en 700. Puede utilizar processUmask para anular los permisos por defecto para grupos y otros usuarios en todos los archivos nuevos creados por MongoDB.

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

mongod --setParameter honorSystemUmask=true

Nota

honorSystemUmask no está disponible en sistemas Windows.

journalCommitInterval

Disponible solo para mongod.

Especifica un número entero entre 1 y 500 que indique el número de milisegundos (ms) entre las confirmaciones de la bitácora.

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 journalCommitInterval a 200 ms:

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

Tip

storage.journal.commitIntervalMs

minSnapshotHistoryWindowInSeconds

Nuevo en la versión 5.0.

Por defecto: 300

Disponible solo para mongod.

El período mínimo de tiempo en segundos durante el cual el motor de almacenamiento conserva el historial de snapshots. Si consultas datos utilizando el nivel de consistencia de lectura "snapshot" y especificas un valor atClusterTime anterior al especificado minSnapshotHistoryWindowInSeconds, mongod devuelve un error SnapshotTooOld.

Advertencia

En los clústeres fragmentados, cambiar el valor predeterminado de minSnapshotHistoryWindowInSeconds en los nodos del servidor de configuración puede causar que las operaciones internas fallen.

No configure minSnapshotHistoryWindowInSeconds a 0 en los nodos del servidor de configuración. Establecer este parámetro en 0 hace que las operaciones internas que realizan lecturas de snapshot dirigidas al servidor de configuración con un atClusterTime especificado fallen.

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.

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

Considera el siguiente ejemplo que establece el minSnapshotHistoryWindowInSeconds a 600 segundos:

db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 600 } )

Nota

Incrementar el valor de minSnapshotHistoryWindowInSeconds incrementa el uso del disco. Para obtener más información, consulte Retención del historial de snapshot.

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

processUmask

Disponible solo para mongod.

Anula los permisos por defecto utilizados para grupos y otros usuarios cuando honorSystemUmask se establece en false. Por defecto, cuando honorSystemUmask está configurado en false, los archivos nuevos creados por MongoDB tienen permisos configurados en 600. Utiliza el parámetro processUmask para anular este valor por defecto con un valor umask personalizado. El propietario del archivo hereda permisos del sistema umask.

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

No puede establecer este parámetro si honorSystemUmask está configurado en true.

Considera el siguiente ejemplo, que establece los permisos para grupos y otros usuarios para que solo puedan leer y guardar, y conserva la configuración del sistema umask para el propietario:

mongod --setParameter processUmask=011

Nota

processUmask no está disponible en sistemas Windows.

storageEngineConcurrentReadTransactions

Disponible solo para mongod.

Por defecto: 0

Cambiado en la 6.0 versión: El wiredTigerConcurrentReadTransactions parámetro pasó a storageEngineConcurrentReadTransactions llamarse.

Disponible solo para el motor de almacenamiento WiredTiger.

Especifica el número máximo de transacciones de lectura concurrentes permitidas en el motor de almacenamiento WiredTiger. Si no se especifica un valor para este parámetro, o se especifica 0, MongoDB utiliza el valor por defecto para su motor de almacenamiento. El valor por defecto para el motor de almacenamiento WiredTiger es 128.

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.

db.adminCommand( { setParameter: 1, storageEngineConcurrentReadTransactions: <num> } )

Tip

wiredTiger.concurrentTransactions

storageEngineConcurrentWriteTransactions

Disponible solo para mongod.

Por defecto: 0

Cambiado en la 6.0 versión: El wiredTigerConcurrentReadTransactions parámetro pasó a storageEngineConcurrentReadTransactions llamarse.

Disponible solo para el motor de almacenamiento WiredTiger.

Especifique el número máximo de transacciones de escritura simultáneas permitidas en el motor de almacenamiento de WiredTiger. Si no especifica un valor para este parámetro o especifica 0, MongoDB usará el valor predeterminado para su motor de almacenamiento. El valor predeterminado para el motor de almacenamiento de WiredTiger es 128.

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.

db.adminCommand( { setParameter: 1, storageEngineConcurrentWriteTransactions: <num> } )

Tip

wiredTiger.concurrentTransactions

syncdelay

Disponible solo para mongod.

Por defecto: 60

Especifique el intervalo en segundos cuando mongod guarda su memoria de trabajo en el disco. Por defecto, mongod guarda la memoria en el disco cada 60 segundos. En casi todas las situaciones, no debería establecer este valor y debería usar la configuración 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.

Considera el siguiente ejemplo que establece el syncdelay a 60 segundos:

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

Para proporcionar datos duraderos, WiredTiger utiliza puntos de control. Para obtener más detalles, consulta Registro en la bitácora y motor de almacenamiento WiredTiger.

Tip

upsertMaxRetryAttemptsOnDuplicateKeyError

Disponible tanto para mongod como para mongos.

Nuevo en la versión 6.0.25.

Número máximo de reintentos cuando una operación de upsert encuentra un error de llave duplicada.

Tipo: entero

Por defecto: 100

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.

Importante

A partir de MongoDB 8.1, si una operación upsert se ejecuta en una transacción de múltiples documentos, entonces upsert no vuelve a intentarlo cuando encuentra un error de clave duplicada.

El siguiente ejemplo establece la cantidad máxima de veces que el servidor reintenta una operación upsert al encontrar un error de clave duplicada en 50.

mongod --setParameter "upsertMaxRetryAttemptsOnDuplicateKeyError=50"

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

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

Parámetros de WiredTiger

wiredTigerEngineRuntimeConfig

Disponible solo para mongod.

Especifique las opciones de configuración del motor de almacenamiento wiredTiger para una instancia en ejecución de mongod.

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

Advertencia

Evite modificar el wiredTigerEngineRuntimeConfig a menos que esté bajo la dirección de los ingenieros de MongoDB, ya que esta configuración tiene importantes implicaciones tanto en WiredTiger como en MongoDB.

Considere el siguiente prototipo de operación:

db.adminCommand({
   "setParameter": 1,
   "wiredTigerEngineRuntimeConfig": "<option>=<setting>,<option>=<setting>"
})

wiredTigerFileHandleCloseIdleTime

Disponible solo para mongod.

Tipo: entero

Por defecto: 600

Especifique la cantidad de tiempo en segundos que un gestor de archivos en wiredTiger puede permanecer inactivo antes de cerrarse.

Si establece wiredTigerFileHandleCloseIdleTime en 0, los elementos inactivos a gestionar no se cierran.

Tip

Este parámetro distingue entre mayúsculas y minúsculas. Si escribes con mayúscula la letra w en wiredTigerFileHandleCloseIdleTime y ejecutas el parámetro, la operación devuelve el siguiente mensaje de error:

{ "code":2,"codeName":"BadValue","errmsg":"Unknown --setParameter 'WiredTigerFileHandleCloseIdleTime'" }

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

Por ejemplo:

mongod --setParameter wiredTigerFileHandleCloseIdleTime=100000

Consulte la documentación de WiredTiger para ver todas las opciones de configuración de WiredTiger disponibles.

Parámetros de auditoría

auditAuthorizationSuccess

Tipo: booleano

Por defecto: false

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

Disponible tanto para mongod como para mongos.

Permite auditar los éxitos de autorización para la acción authCheck.

Cuando auditAuthorizationSuccess es false, el sistema de auditoría solo registra los fallos de autorización para authCheck.

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 habilitar la auditoría de los éxitos de autorización, emite el siguiente comando:

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

Habilitar auditAuthorizationSuccess degrada el rendimiento más que registrar solo los fallos de autorización.

Si la configuración de auditoría en tiempo de ejecución está activada, el parámetro auditAuthorizationSuccess no debe aparecer en el archivo de configuración mongod o mongos. El servidor no se iniciará si el parámetro está presente.

Tip

getParameter

auditConfigPollingFrequencySecs

Nuevo en la versión 5.0.

Tipo: entero

Por defecto: 300

Un clúster puede tener servidores que mantienen la configuración de auditoría para el clúster. Establece el intervalo, en segundos, para que los servidores no configurados consulten un servidor de configuración para la generación actual de auditoría. Si este valor devuelto difiere del valor conocido anteriormente, el nodo iniciador solicitará la configuración actual y actualizará su estado interno.

Nota

Si se utiliza el valor predeterminado de 300 segundos, los nodos que no están configurados pueden demorarse hasta 5 minutos con respecto a un comando setAuditConfig.

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

auditEncryptionHeaderMetadataFile

Novedades en la versión 6.0.

Tipo: string

Nota

Disponible solo en MongoDB Enterprise. MongoDB Enterprise y Atlas tienen diferentes requisitos de configuración.

Disponible tanto para mongod como para mongos.

Ruta y nombre del archivo para el registro de encabezados de auditoría de metadatos para el cifrado de registros de auditoría. Un encabezado se coloca en la parte superior de cada entrada de registro de auditoría y contiene metadatos para descifrar el registro de auditoría. Los encabezados también se almacenan en el registro de auditoría.

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

Por ejemplo, a continuación se establece la ruta y el archivo para auditEncryptionHeaderMetadataFile:

mongod --setParameter auditEncryptionHeaderMetadataFile=/auditFiles/auditHeadersMetadataFile.log

auditEncryptKeyWithKMIPGet

Novedades en la versión 6.0.

Tipo: booleano

Por defecto: false

Nota

Disponible solo en MongoDB Enterprise. MongoDB Enterprise y Atlas tienen diferentes requisitos de configuración.

Disponible tanto para mongod como para mongos.

Habilita el cifrado de registro de auditoría para servidores del Protocolo de Interoperabilidad de Gestión de Claves (KMIP) que solo soportan la versión 1.0 o 1.1 del protocolo KMIP.

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

El siguiente ejemplo establece auditEncryptKeyWithKMIPGet a true:

mongod --setParameter auditEncryptKeyWithKMIPGet=true

Parámetros de transacción

coordinateCommitReturnImmediatelyAfterPersistingDecision

Nuevo en la versión 5.0.

Actualizado en la versión 6.0 y en 5.0.10

Tipo: booleano

Por defecto: false

Cuando se establece en false, el coordinador de transacciones de particiones espera a que todas las particiones que participan verifiquen la decisión de confirmar o cancelar una transacción multi-documento antes de devolver el resultado al cliente.
Cuando se establece en true, el coordinador de transacciones de particiones devuelve al cliente una decisión de transacción multi-documento en cuanto la decisión se convierte en durable con el nivel de confirmación de escritura solicitado para la transacción.
Si el cliente solicitó un nivel de confirmación de escritura inferior a "majority", la confirmación puede revertirse después de que se devuelva la decisión al cliente.
Las transacciones pueden no tener coherencia de “lectura de sus escrituras”. Es decir, una operación de lectura puede no mostrar los resultados de las operaciones de escritura que la precedieron. Esto puede ocurrir si:
- Una transacción se tiene que escribir en varios fragmentos.
- La lectura y el guardado anterior tienen lugar en diferentes sesiones.
La coherencia causal solo garantiza la relación causal de las lecturas y las escrituras que ocurren dentro de la misma sesión.

El coordinador de transacciones de fragmentos devuelve una decisión de confirmación de transacción de múltiples documentos al cliente tan pronto como la decisión se vuelve duraderacon la preocupación de escritura de transacción solicitada.

Si el cliente solicitó un nivel de confirmación de escritura inferior a "majority", la confirmación puede revertirse después de que se devuelva la decisión al cliente.

Es posible que las transacciones no tengan la consistencia de "leer sus escrituras". Es decir, una operación de lectura podría no reflejar los resultados de una operación de escritura anterior. Esto puede ocurrir en los siguientes casos:

Una transacción se tiene que escribir en varios fragmentos.
La lectura y el guardado anterior tienen lugar en diferentes sesiones.

Laconsistencia causal solo garantiza la relación causal de lecturas y escrituras que ocurren dentro de la misma sesió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.

Ejemplo

El siguiente ejemplo asigna coordinateCommitReturnImmediatelyAfterPersistingDecision a true:

mongod --setParameter coordinateCommitReturnImmediatelyAfterPersistingDecision=true

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

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

internalSessionsReapThreshold

Novedades en la versión 6.0.

Disponible tanto para mongod como para mongos.

Por defecto: 1000

Límite de sesión para la eliminación de metadatos internos de sesión. Los metadatos:

Contiene información sobre transacciones de sesión para las operaciones de los usuarios.
Se almacena en la colección config.transactions.

Cuando el número de sesiones internas es mayor que internalSessionsReapThreshold, los metadatos se borran.

Si configura internalSessionsReapThreshold en 0, los metadatos internos de la sesión solo se borran cuando termina la sesión del usuario.

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 internalSessionsReapThreshold en 500 sesiones:

db.adminCommand( { setParameter: 1, internalSessionsReapThreshold: 500 } )

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

mongod --setParameter internalSessionsReapThreshold=500

transactionLifetimeLimitSeconds

Disponible solo para mongod.

Por defecto: 60

Especifica la duración de las transacciones multi-documento. Las transacciones que excedan este límite se consideran caducadas y serán abortadas por un proceso de limpieza periódico. El proceso de limpieza se ejecuta cada transactionLifetimeLimitSeconds/2 segundos o al menos una vez cada 60 segundos.

El proceso de limpieza ayuda a aliviar la presión del caché de almacenamiento.

El valor mínimo para transactionLifetimeLimitSeconds es 1 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.

Lo siguiente configura el transactionLifetimeLimitSeconds en 30 segundos:

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

También puede configurar el parámetro transactionLifetimeLimitSeconds al inicio.

mongod --setParameter "transactionLifetimeLimitSeconds=30"

Para establecer el parámetro para un clúster, el parámetro debe modificarse para todos los miembros del set de réplicas de cada fragmento.

A partir de MongoDB 5.0, si cambias el parámetro transactionLifetimeLimitSeconds, también debes cambiar transactionLifetimeLimitSeconds al mismo valor en todos los miembros del set de réplicas del servidor de configuración. Si manteienes este valor coherente:

Garantiza que el historial de la tabla de enrutamiento se conserve al menos durante el tiempo límite de vida de las transacciones en los miembros del set de réplicas del fragmento.
Reduce la frecuencia de reintentos de transacciones y, por lo tanto, mejora el rendimiento.

transactionTooLargeForCacheThreshold

Nuevo en la versión 6.0.5.

Disponible solo para mongod.

Tipo: decimal

Por defecto: 0,75

El valor umbral para reintentar las transacciones que fallan debido a la presión de la caché. El valor es un porcentaje del tamaño de la caché sucia. El valor por defecto, 0.75, representa el 75 % de la caché sucia.

La caché sucia está limitada al 20 % del tamaño total de la caché. Cuando transactionTooLargeForCacheThreshold se establece en 0.75, el servidor solo reintenta transacciones que utilizan menos del 15 % (0.75 * 20%) de la caché total del motor de almacenamiento.

El límite solo se aplica a los reintentos. Las transacciones grandes pueden utilizar más del transactionTooLargeForCacheThreshold por ciento de la caché sucia. Sin embargo, si una transacción grande se revierte debido a la presión de la caché, el servidor genera un error TransactionTooLargeForCache y no vuelve a intentar la transacción.

Para deshabilitar este comportamiento, establece transactionTooLargeForCacheThreshold en 1.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.

Para obtener más información sobre el almacenamiento de WiredTiger, consulte las storage.wiredTiger opciones.

maxTransactionLockRequestTimeoutMillis

Disponible solo para mongod.

Tipo: entero

Por defecto: 5

La cantidad máxima de tiempo en milisegundos que las transacciones multidocumento deben esperar para adquirir los bloqueos requeridos por las operaciones en la transacción.

Si la transacción no puede adquirir los bloqueos después de esperar maxTransactionLockRequestTimeoutMillis, la transacción se aborta.

Por defecto, las transacciones multidocumento tardan 5 milisegundos. Es decir, si la transacción no puede adquirir los bloqueos dentro de 5 milisegundos, la transacción se cancela. Si una operación proporciona un tiempo de espera mayor en una solicitud de bloqueo, maxTransactionLockRequestTimeoutMillis anula el tiempo de espera específico de la operación.

Puede establecer maxTransactionLockRequestTimeoutMillis en:

0 de tal manera que si la transacción no puede adquirir los bloqueos necesarios de inmediato, la transacción se aborta.
Un número mayor que 0 para esperar el tiempo especificado para adquirir los bloqueos necesarios. Esto puede ayudar a obviar abortos de transacciones en adquisiciones de bloqueos concurrentes momentáneas, como operaciones rápidas de metadatos. Sin embargo, esto podría demorar el aborto de las operaciones de transacciones en estado de bloqueo.
-1 para usar el tiempo de espera específico de la operació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.

Lo siguiente configura el maxTransactionLockRequestTimeoutMillis a 20 milisegundos:

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

También puede establecer este parámetro durante el inicio:

mongod --setParameter maxTransactionLockRequestTimeoutMillis=20

Volver

Ajustes de archivo de configuración y asignación de opciones de línea de comandos

Cluster Parameters