mongod

Opciones principales

--auth

Permite la autorización para controlar el acceso del usuario a los recursos y operaciones de la base de datos. Cuando la autorización está activada, MongoDB requiere que todos los clientes se autentiquen primero para determinar el acceso del cliente.

Para configurar usuarios, utilice el cliente mongosh. Si no existen usuarios, la interfaz de localhost tiene acceso a la base de datos hasta que cree el primer usuario.

Consulte Seguridad para obtener más información.

--bind_ip <hostnames|ipaddresses|Unix domain socket paths>

Por defecto: localhost

Los nombres de host, las direcciones IP y las rutas completas de los sockets de dominio Unix en los que mongod debería escuchar las conexiones de los clientes. Puedes conectar mongod a cualquier interfaz. Para vincularse a varias direcciones, introduce una lista de valores separados por comas.

Ejemplo

localhost,/tmp/mongod.sock

Se puede especificar tanto direcciones IPv4 como IPv6, o nombres de host que se resuelvan en una dirección IPv4 o IPv6.

Ejemplo

localhost, 2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513

Nota

Si especifica una dirección IPv6 o un nombre de host que se resuelva a una dirección IPv6 para --bind_ip, debe empezar mongod con --ipv6 para habilitar el soporte IPv6. Especificar una dirección IPv6 en --bind_ip no habilita el soporte para IPv6.

Si especificas una dirección IPv6 de enlace local (fe80::/10), debe añadir el índice de zona a esa dirección (es decir, fe80::<address>%<adapter-name>).

Ejemplo

localhost,fe80::a00:27ff:fee0:1fcf%enp0s3

Importante

Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.

Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.

Advertencia

Antes de vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar la infraestructura de red.

Para obtener más información sobre la vinculación de IP, consulta la documentación de Vinculación de IP en implementaciones autogestionadas.

Para vincularse a todas las direcciones IPv4, introduzca 0.0.0.0.

Para conectarse a todas las direcciones IPv4 e IPv6, introduzca ::,0.0.0.0 o un asterisco "*" (escriba el asterisco entre comillas para evitar la expansión del patrón de nombre de archivo). O bien, utilice la configuración net.bindIpAll.

Nota

• --bind_ip y --bind_ip_all son mutuamente excluyentes. Especificar ambas opciones hace que mongod genere un error y se detenga.

• La opción de línea de comandos --bind anula la configuración del archivo net.bindIp.

--bind_ip_all

Si se especifica, la instancia mongod se enlaza a todas las direcciones IPv4 (es decir, 0.0.0.0). Si mongod comienza con --ipv6, --bind_ip_all también se enlaza a todas las direcciones IPv6 (es decir, ::).

mongod Solo admite IPv6 si se inicia con.--ipv6 --bind_ip_all Especificar por sí solo no6 habilita la compatibilidad con IPv.

Advertencia

Antes de vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar la infraestructura de red.

Para obtener más información sobre la vinculación de IP, consulta la documentación de Vinculación de IP en implementaciones autogestionadas.

Si no, puede establecer la opción --bind_ip en ::,0.0.0.0 o en un asterisco "*" (escriba el asterisco entre comillas para evitar la expansión del patrón de nombre de archivo).

Nota

--bind_ip y --bind_ip_all son mutuamente excluyentes. Es decir, puede especificar uno u otro, pero no ambos.

--clusterIpSourceAllowlist <string>

Nuevo en la versión 5.0.

Una lista de direcciones IP/CIDR (Classless Inter-Domain Routing) contra las cuales mongod valida las solicitudes de autenticación de otros miembros del set de réplicas y, si forma parte de un clúster, las instancias de mongos. mongod verifica que la IP de origen esté explícitamente en la lista o pertenezca a un rango CIDR de la lista. Si la dirección IP no está presente, el servidor no autentica el mongod ni el mongos.

--clusterIpSourceAllowlist no tiene efecto en un mongod iniciado sin autenticación.

--clusterIpSourceAllowlist acepta múltiples direcciones IPv4/6 separadas por comas o rangos de enrutamiento entre dominios sin clases (CIDR):

mongod --clusterIpSourceAllowlist 192.0.2.0/24,127.0.0.1,::1

Importante

Asegúrate de que --clusterIpSourceAllowlist incluya la dirección IP o los rangos CIDR que incluyan la dirección IP de cada set de réplicas o mongos en la implementación para garantizar una comunicación adecuada entre los componentes del clúster.

--config <filename>, -f <filename>

Especifica un archivo de configuración para las opciones de configuración en tiempo de ejecución. El archivo de configuración es el método preferido para la configuración en tiempo de ejecución de mongod. Estas opciones son equivalentes a las opciones de configuración de la línea de comandos. Consulta Opciones del archivo de configuración autogestionada para obtener más información.

Asegúrese de que el archivo de configuración utilice codificación ASCII. La instancia mongod no admite archivos de configuración con la codificación no ASCII, incluido UTF-8.

--configExpand <none|rest|exec>

Por defecto: ninguno

Permite usar Directivas de expansión en archivos de configuración. Las directivas de expansión permiten establecer valores de origen externo para las opciones del archivo de configuración.

--configExpand ofrece soporte para las siguientes directivas de expansión:

Valor	Descripción
none	Predeterminado. mongod no expande las directrices de expansión. mongod no se inicia si alguna configuración de archivo utiliza directivas de expansión.
rest	mongod expande __rest directivas de expansión al analizar el archivo de configuración.
exec	mongod expande __exec directivas de expansión al analizar el archivo de configuración.

Puede especificar varias directivas de expansión como una lista separada por comas, por ejemplo: rest, exec. Si el archivo de configuración contiene directivas de expansión no especificadas en --configExpand, el mongod devuelve un error y termina.

Consulte Valores de archivos de configuración de origen externo para implementaciones autoadministradas para obtener más información sobre las directivas de expansión de los archivos de configuración.

--filePermissions <path>

Por defecto: 0700

Establece los permisos para el archivo de socket de dominio UNIX.

--filePermissions se aplica únicamente a sistemas basados en Unix.

--fork

Activa el modo demonio que ejecuta el proceso mongod en segundo plano. La opción --fork no es compatible con Windows.

Por defecto, mongod no se ejecuta como demonio. Debe gestionar mongod como un demonio mediante --fork o un proceso de control que gestione la demonización, como upstart o systemd.

Para utilizar --fork, configure la salida de registros para el mongod con uno de los siguientes:

• --logpath

• --syslog

--help, -h

Devuelve información sobre las opciones y el uso de mongod.

--ipv6

Habilita el soporte para IPv6. mongod desactiva el soporte de IPv6 por defecto.

Configurar --ipv6 no dirige a mongod a escuchar en ninguna dirección o interfaz local IPv6. Para configurar mongod para escuchar en una interfaz IPv6, debe:

• Configura --bind_ip con una o más direcciones IPv6 o nombres de host que se resuelvan en direcciones IPv6, o

• Establece --bind_ip_all en true.

--keyFile <file>

Especifica la ruta a un archivo de claves que almacena el secreto compartido que las instancias de MongoDB utilizan para autenticarse entre sí en un clúster particionado o set de réplicas. --keyFile implica --auth. Consulte Autenticación autogestionada interna/de miembros para obtener más información.

Los archivos de claves para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo de claves. El formato YAML acepta:

• Una string de clave única (igual que en versiones anteriores)

• Una secuencia de cadenas clave

El formato YAML es compatible con los archivos de claves de una sola clave existentes que utilizan el formato de archivo de texto.

--listenBacklog <number>

Por defecto: constante SOMAXCONN del sistema de destino

La cantidad máxima de conexiones que puede haber en la cola de escucha.

Advertencia

Se debe consultar la documentación del sistema local para entender las limitaciones y los requisitos de configuración antes de usar este parámetro.

Importante

Para prevenir un comportamiento indefinido, se especifica un valor para este parámetro entre 1 y la constante SOMAXCONN del sistema local.

El valor predeterminado para el listenBacklog parámetro se establece SOMAXCONN enSOMAXCONN el momento de la compilación en la constante del sistema de destino. es el valor válido máximo que se documenta para el parámetro backlog en la llamada del sistema de escucha.

Algunos sistemas pueden interpretar SOMAXCONN de forma simbólica y otros numéricamente. El listen backlog real aplicado en la práctica puede diferir de cualquier interpretación numérica de la constante SOMAXCONN o argumento de --listenBacklog, y también puede estar limitado por configuraciones del sistema como net.core.somaxconn en Linux.

Pasar un valor para el parámetro listenBacklog que exceda la constante SOMAXCONN del sistema local es, según la letra de las normas, un comportamiento indefinido. Los valores más altos pueden ser truncados silenciosamente como enteros, ser ignorados, provocar un consumo inesperado de recursos o tener otras consecuencias adversas.

En sistemas con cargas de trabajo que presentan picos de conexión, para los cuales se sabe empíricamente que el sistema local puede respetar valores más altos para el parámetro backlog que la SOMAXCONN constante, configurar el listenBacklog parámetro en un valor más alto puede reducir la latencia de la operación según lo observado por el cliente al reducir la cantidad de conexiones que se ven obligadas a entrar en un estado de retroceso.

--logappend

Agrega nuevas entradas al final de la entrada de registro existente cuando la instancia de mongod se reinicia. Sin esta opción, mongod realiza una copia de seguridad del registro existente y crea un archivo nuevo.

--logpath <path>

Se debe enviar toda la información de registro de diagnóstico a una entrada de registro en lugar de a la salida estándar o al sistema syslog del host. MongoDB crea la entrada de registro en la ruta que se especifique.

Por defecto, MongoDB mueve cualquier entrada de registro existente en lugar de sobrescribirla. Para anexar a la entrada de registro, establezca la opción --logappend.

--logRotate <string>

Por defecto: renombrar

Determina el comportamiento del comando logRotate al rotar el registro del servidor y/o el registro para auditoría. Especifique ya searename o reopen:

• rename Renombra la entrada de registro.

• reopen Cierra y vuelve a abrir la entrada de registro siguiendo el comportamiento típico de rotación de registros en Linux/Unix. Utilice reopen cuando use la utilidad de rotación de registros en Linux/Unix logrotate para evitar la pérdida de registros.

  Si especifica reopen, también debe usar --logappend.

--maxConns <number>

El número máximo de conexiones simultáneas que mongod acepta. Esta configuración no tiene efecto si es superior al umbral máximo de seguimiento de conexión configurado por el sistema operativo.

No asignes un valor demasiado bajo para esta opción, o encontrarás errores durante la operación normal de la aplicación.

--networkMessageCompressors <string>

Default: snappy,zstd,zlib

Especifica los compresores por defecto que se utilizarán para la comunicación entre esta instancia mongod y:

• otros miembros de la implementación si la instancia es parte de un set de réplicas o un clúster

• mongosh

• controladores con soporte para el formato de mensaje OP_COMPRESSED.

MongoDB es compatible con los siguientes compresores:

• rápido

• zlib

• zstd

Nota

Tanto la instancia mongod como la instancia mongos tienen compresores snappy,zstd,zlib por defecto, en ese orden.

Para desactivar la compresión de red, establezca el valor en disabled.

Importante

Los mensajes se comprimen cuando ambas partes permiten la compresión de red. De lo contrario, los mensajes entre las partes no se comprimen.

Si especifica varios compresores, el orden en el que enumera los compresores es importante, así como el iniciador de la comunicación. Por ejemplo, si mongosh especifica los siguientes compresores de red zlib,snappy, y mongod especifica snappy,zlib, los mensajes entre mongosh y mongod usan zlib.

Si las partes no comparten al menos un compresor común, los mensajes entre las partes quedan sin comprimir. Por ejemplo, si mongosh especifica el compresor de red zlib y mongod especifica snappy, los mensajes entre mongosh y mongod no se comprimen.

--noauth

Desactiva la autenticación. Actualmente es el valor por defecto. Existe por motivos de compatibilidad y claridad en el futuro.

--noscripting

Desactiva el motor de scripts.

--notablescan

Prohíbe las operaciones que requieren un escaneo de colección. Consulta notablescan para obtener información adicional.

--nounixsocket

Desactiva la escucha en el socket de dominio UNIX. --nounixsocket solo se aplica a sistemas basados en Unix.

El proceso mongod siempre escucha en el socket UNIX a menos que se cumpla alguna de las siguientes condiciones:

• --nounixsocket está configurado

• net.bindIp no está configurado

• net.bindIp no especifica localhost ni su dirección IP asociada

mongod instalados desde los paquetes oficiales de instalación de MongoDB Community Edition en Debian y de instalación de MongoDB Community Edition en Red Hat o CentOS tienen la configuración bind_ip establecida en 127.0.0.1 por defecto.

--outputConfig

Envía las mongod opciones de configuración de la instancia, con formato YAML, a stdout y sale de la mongod instancia. Para las opciones de configuración que utilizan valores de archivo de configuración de origen externo para implementaciones autogestionadas, --outputConfig devuelve el valor resuelto de dichas opciones.

Advertencia

Esto puede incluir cualquier contraseña configurada o secretos previamente ocultos a través de la fuente externa.

Para ejemplos de uso, consulte:

• Genere el archivo de configuración con los valores resueltos de la directiva de expansión

• Convierta las opciones de línea de comandos autogestionadas a YAML

--pidfilepath <path>

Especifica una ubicación de archivo para almacenar el ID de proceso (PID) del proceso mongod. El usuario que ejecuta el proceso mongod o mongos debe poder escribir en esta ruta. Si no se especifica la opción --pidfilepath, el proceso no crea un archivo PID. Esta opción generalmente solo es útil en combinación con la opción --fork.

Nota

Linux

En Linux, la gestión de archivos PID generalmente es responsabilidad del sistema de inicialización de la distribución: usualmente un archivo de servicio en el directorio /etc/init.d, o un archivo de unidad systemd registrado con systemctl. Se debe usar solo la opción --pidfilepath si no se usa uno de estos sistemas de inicialización. Para obtener más información, se debe consultar la Guía de instalación correspondiente al sistema operativo.

Nota

macOS

En macOS, la gestión de archivos PID generalmente está a cargo de brew. Se debe usar solo la opción --pidfilepath si no se usa brew en el sistema macOS. Para obtener más información, se debe consultar la Guía de instalación correspondiente al sistema operativo.

--port <port>

Por defecto:

• 27017 si mongod no es un nodo de partición ni un nodo de servidor de configuración

• 27018 si mongod es un shard member

• 27019 si mongod es un config server member

El puerto TCP en el que la instancia de MongoDB escucha las conexiones de los clientes.

Modificado en la 7.0.3 versión: La --port opción acepta un rango de valores entre 0 y.65535 Al establecer el puerto en, se 0 configura mongod para usar un puerto arbitrario asignado por el sistema operativo.

--quiet

Ejecuta mongod en modo silencioso que intenta limitar la cantidad de salida.

Esta opción suprime:

• resultado de los comandos de base de datos

• Actividad de replicación

• eventos de aceptación de conexión

• eventos de cierre de conexión

--redactClientLogData

Disponible solamente en MongoDB Enterprise.

Un mongod que se ejecuta con --redactClientLogData redacta cualquier mensaje que acompaña a un evento de registro determinado antes de registrarlo. Esto impide que el mongod 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.

Por ejemplo, una implementación de MongoDB podría almacenar Información Personal Identificable (PII) en una o más colecciones. mongod registra eventos como los relacionados con operaciones CRUD, metadatos de particionado, etc. Es posible que mongod pueda exponer PII como parte de estas operaciones de registro. Un mongod que se ejecuta con --redactClientLogData remueve cualquier mensaje que acompañe a estos eventos antes de que se envíe al registro, y elimina efectivamente la PII.

El diagnóstico en un mongod que funciona con --redactClientLogData puede ser más complicado debido a la falta de datos relacionados con un evento de registro. Consulte la página del manual de registro de procesos para ver un ejemplo del efecto de --redactClientLogData en la salida de los registros.

En un mongod en ejecución, utilice setParameter con el parámetro redactClientLogData para configurar esta opción.

--setParameter <options>

Especifica uno de los parámetros de MongoDB descritos en Parámetros de MongoDB Server para una implementación autogestionada. Puedes especificar múltiples campos setParameter.de

--shutdown

La opción --shutdown termina de forma limpia y segura el proceso mongod. Al invocar mongod con esta opción, debe establecer la opción --dbpath directamente o mediante el archivo de configuración y la opción --config.

La opción --shutdown está disponible solo en sistemas Linux.

Para obtener información sobre formas adicionales de apagado, consulte también Detener procesos mongod.

--sysinfo

Devuelve la información del sistema de diagnóstico y luego termina. La información proporciona el tamaño de la página, el número de páginas físicas y el número de páginas físicas disponibles.

--syslog

Envía toda la salida de registro al sistema syslog del host en lugar de a la salida estándar o a una entrada de registro (--logpath).

La opción --syslog no es compatible con Windows.

Advertencia

El demonio syslog genera marcas de tiempo cuando registra un mensaje, no cuando MongoDB emite el mensaje. Esto puede llevar a marcas de tiempo engañosas en las entradas de registro, especialmente cuando el sistema está bajo una carga pesada. Recomendamos utilizar la opción --logpath para los sistemas de producción a fin de garantizar marcas de tiempo precisas.

MongoDB incluye el componente en sus mensajes de registros para syslog.

...  ACCESS   [repl writer worker 5] Unsupported modification to roles collection ...

--syslogFacility <string>

Por defecto: usuario

Especifica el nivel de instalación utilizado al registrar mensajes en syslog. El valor que especifique debe ser compatible con la implementación de syslog de su sistema operativo. Para usar esta opción, debe activar la opción --syslog.

--timeStampFormat <string>

Default: iso8601-local

El formato de hora para las marcas de tiempo en los mensajes de registro. Especifique uno de los siguientes valores:

Valor	Descripción
iso8601-utc	Muestra las marcas de tiempo en Tiempo Universal Coordinado (UTC) en el formato ISO-8601. Por ejemplo, para Nueva York al inicio del Epoch: 1970-01-01T00:00:00.000Z
iso8601-local	Muestra las marcas de tiempo en la hora local en el formato ISO-8601. Por ejemplo, para Nueva York al inicio del Epoch: 1969-12-31T19:00:00.000-05:00

Nota

--timeStampFormat ya no es compatible con ctime. Un ejemplo de una fecha con formato ctime es: Wed Dec 31 18:17:54.811.

--timeZoneInfo <path>

La ruta completa desde la cual cargar la base de datos de la zona horaria. Si no se proporciona esta opción, MongoDB utiliza su base de datos de zona horaria incorporada.

El archivo de configuración incluido con los paquetes de Linux y macOS establece la ruta de la base de datos de la zona horaria en /usr/share/zoneinfo por defecto.

La base de datos de zonas horarias incorporada es una copia de la base de datos de zonas horarias Olson/IANA. Se actualiza junto con las versiones de MongoDB, pero el ciclo de lanzamiento de la base de datos de zonas horarias es diferente al ciclo de lanzamiento de MongoDB. La versión más reciente de la base de datos de zonas horarias está disponible en nuestro sitio de descarga.

wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip
unzip timezonedb-latest.zip
mongod --timeZoneInfo timezonedb-2017b/

Advertencia

MongoDB utiliza la biblioteca de terceros timelib para proporcionar conversiones precisas entre zonas horarias. Debido a una actualización reciente, timelib podía crear conversiones de zonas horarias inexactas en las versiones anteriores de MongoDB.

Para vincular explícitamente a la base de datos de zona horaria en versiones de MongoDB anteriores a 5.0, descarga la base de datos de zona horaria y usa el parámetro timeZoneInfo.

Tip

processManagement.timeZoneInfo.

--traceExceptions

Solo para uso diagnóstico interno.

--transitionToAuth

Permite al mongod aceptar y crear conexiones autenticadas y no autenticadas hacia y desde otras instancias de mongod y mongos en la implementación. Se utiliza para realizar la transición continua de sets de réplicas o clústeres particionados de una configuración sin autenticación a autenticación interna. Requiere especificar un mecanismo de autenticación interno como --keyFile.

Por ejemplo, si se utilizan keyfiles para la autenticación interna, el mongod establece una conexión autenticada con cualquier mongod o mongos en la implementación mediante un keyfile coincidente. Si los mecanismos de seguridad no coinciden, el mongod utiliza una conexión no autenticada en su lugar.

Un mongod que se ejecuta con --transitionToAuth no aplica controles de acceso de usuarios. Los usuarios pueden conectarse a su implementación sin ninguna verificación de control de acceso y realizar operaciones administrativas y de lectura y escritura.

Nota

Un mongod que se ejecuta con autenticación interna y sin --transitionToAuth requiere que los clientes se conecten con controles de acceso de usuario. Actualice los clientes para conectarse a mongod con el usuario apropiado antes de reiniciar mongod sin --transitionToAuth.

--unixSocketPrefix <path>

Por defecto: /tmp

La ruta para el socket UNIX. --unixSocketPrefix se aplica únicamente a sistemas basados en Unix.

Si esta opción no tiene valor, el proceso mongod crea un socket con /tmp como prefijo. MongoDB crea y escucha en un socket UNIX a menos que una de las siguientes condiciones sea verdadera:

• net.unixDomainSocket.enabled es false

• --nounixsocket está configurado

• net.bindIp no está configurado

• net.bindIp no especifica localhost ni su dirección IP asociada

--verbose, -v

Aumenta la cantidad de reportes internos devueltos en la salida estándar o en las entradas de registro. Aumente el nivel de verbosidad con el formulario -v al incluir la opción varias veces, por ejemplo: -vvvvv.

Nota

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.

--version

Devuelve el número de la versión mongod.

Opciones de autenticación o autorización de LDAP

--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>

Disponible solamente en MongoDB Enterprise.

El servidor LDAP contra el cual el mongod autentica a los usuarios o determina qué acciones está autorizado a realizar un usuario en una base de datos dada. Si el servidor LDAP especificado tiene instancias replicadas, puedes especificar el host y el puerto de cada servidor replicado en una lista delimitada por comas.

Si su infraestructura LDAP particiona el directorio LDAP entre varios servidores LDAP, especifique un servidor LDAP o cualquiera de sus instancias replicadas en. MongoDB admite las siguientes --ldapServers referencias LDAP, tal como se define en RFC..4511 4.110 No utilice para listar todos los servidores LDAP de su --ldapServers infraestructura.

Esta configuración se puede configurar en un mongod en ejecución al utilizar setParameter.

Si no se configura, mongod no puede utilizar la autenticación o la autorización LDAP.

--ldapValidateLDAPServerConfig <boolean>

Disponible en MongoDB Enterprise

Una bandera que determina si la instancia mongod verifica la disponibilidad de LDAP server(s) como parte del inicio:

• Si es true, la instancia de mongod realiza la comprobación de disponibilidad y solo continúa iniciándose si el servidor LDAP está disponible.

• Si es false, la instancia mongod omite la verificación de disponibilidad; es decir, la instancia se inicia incluso si el servidor LDAP no está disponible.

--ldapQueryUser <string>

Disponible solamente en MongoDB Enterprise.

La identidad con la que mongod se vincula al conectarse o realizar queries en un servidor LDAP.

Solo es necesario si alguna de las siguientes condiciones es verdadera:

• Usando autorizacion LDAP.

• Uso de una query LDAP para username transformation.

• El servidor LDAP no permite conexiones anónimas

Debe utilizar --ldapQueryUser con --ldapQueryPassword.

Si no se establece, mongod no intenta vincularse al servidor LDAP.

Esta configuración se puede configurar en un mongod en ejecución al utilizar setParameter.

Nota

Las implementaciones de MongoDB en Windows pueden usar --ldapBindWithOSDefaults en lugar de --ldapQueryUser y --ldapQueryPassword. No puedes especificar --ldapQueryUser y --ldapBindWithOSDefaults al mismo tiempo.

--ldapQueryPassword <string | array>

Disponible solamente en MongoDB Enterprise.

La contraseña utilizada para enlazarse a un servidor LDAP al usar --ldapQueryUser. Debes utilizar --ldapQueryPassword con --ldapQueryUser.

Si no está configurado, mongod no intenta conectarse al servidor LDAP.

Puede configurar esta opción en un mongod en ejecución mediante setParameter.

El comando ldapQueryPassword setParameter acepta una string o un arreglo de strings. Si ldapQueryPassword se establece en un arreglo, MongoDB intenta cada contraseña en orden hasta que una funcione. Utiliza un arreglo de contraseñas para cambiar la contraseña de la cuenta LDAP sin tiempo de inactividad.

--ldapBindWithOSDefaults <bool>

Por defecto: false

Disponible solo en MongoDB Enterprise para la plataforma Windows.

Permite que mongod se autentique o vincule mediante sus credenciales de inicio de sesión de Windows al conectarse al servidor LDAP.

Solo es requerido si:

• Usando autorizacion LDAP.

• Uso de una query LDAP para username transformation.

• El servidor LDAP no permite conexiones anónimas

Utiliza --ldapBindWithOSDefaults para reemplazar --ldapQueryUser y --ldapQueryPassword.

--ldapBindMethod <string>

Por defecto: simple

Disponible solamente en MongoDB Enterprise.

El método que mongod utiliza para autenticarse en un servidor LDAP. Utilícelo con --ldapQueryUser y --ldapQueryPassword para conectarse al servidor LDAP.

--ldapBindMethod admite los siguientes valores:

• simple - mongod utiliza autenticación sencilla.

• sasl - mongod utiliza el protocolo SASL para la autenticación

Si especifica sasl, puede configurar los mecanismos SASL disponibles mediante --ldapBindSaslMechanisms. mongod tiene por defecto el uso del mecanismo DIGEST-MD5.

--ldapBindSaslMechanisms <string>

Por defecto: DIGEST-MD5

Disponible solamente en MongoDB Enterprise.

Una lista separada por comas de los mecanismos SASL que mongod puede utilizar al autenticarse en el servidor LDAP. El mongod y el servidor LDAP deben coincidir en al menos un mecanismo. mongod carga dinámicamente cualquier biblioteca de mecanismos SASL instalada en la máquina host en tiempo de ejecución.

Instale y configure las librerías adecuadas para los mecanismos SASL seleccionados tanto en el host mongod como en el host del servidor LDAP remoto. Su sistema operativo puede incluir ciertas bibliotecas SASL por defecto. Consulte la documentación asociada con cada mecanismo SASL para obtener orientación sobre la instalación y configuración.

Si usas el mecanismo SASL GSSAPI para la autenticación Kerberos en implementaciones autogestionadas, verifica lo siguiente para la máquina host mongod:

Linux

• La variable de entorno KRB5_CLIENT_KTNAME se resuelve en el nombre de los Archivos Keytab de Linux del cliente para la máquina host. Para obtener más información sobre las variables de entorno de Kerberos, consulta la documentación de Kerberos.

• El keytab del cliente incluye un Usuario principal para que mongod lo utilice al conectarse al servidor LDAP y ejecutar consultas LDAP.

Windows

Si se conecta a un servidor de Active Directory, la configuración de Kerberos de Windows genera automáticamente un Ticket-Granting-Ticket cuando el usuario inicia sesión en el sistema. Establezca --ldapBindWithOSDefaults en true para permitir que mongod utilice las credenciales generadas al conectarse al servidor de Active Directory y ejecutar queries.

Establece --ldapBindMethod en sasl para usar esta opción.

Nota

Para obtener una lista completa de los mecanismos SASL, se debe consultar el listado de IANA. Se debe consultar la documentación del servicio LDAP o Active Directory para identificar los mecanismos SASL compatibles con el servicio.

MongoDB no es una fuente de bibliotecas de mecanismos SASL, ni la documentación de MongoDB es una fuente definitiva para instalar o configurar cualquier mecanismo SASL. Para obtener documentación y soporte, consulte al proveedor o propietario de la biblioteca de mecanismos SASL.

Para obtener más información sobre SASL, consulte los siguientes recursos:

• Para Linux, consulta la documentación de Cyrus SASL.

• Para Windows, consulta la documentación de Windows SASL.

--ldapTransportSecurity <string>

Por defecto: tls

Disponible solamente en MongoDB Enterprise.

Por defecto, mongod crea una conexión segura TLS/SSL al servidor LDAP.

Para las implementaciones de Linux, debe configurar las opciones adecuadas de TLS en el archivo /etc/openldap/ldap.conf. El administrador de paquetes de su sistema operativo crea este archivo como parte de la instalación de MongoDB Enterprise, mediante la dependencia libldap. Consulte la documentación para TLS Options en la documentación ldap.conf de OpenLDAP para obtener instrucciones más completas.

Para la implementación de Windows, debe agregar los certificados CA del servidor LDAP a la herramienta de gestión de certificados de Windows. El nombre exacto y la funcionalidad de la herramienta pueden variar según la versión del sistema operativo. Consulte la documentación de su versión de Windows para obtener más información sobre la gestión de certificados.

Establezca --ldapTransportSecurity en none para desactivar TLS/SSL entre mongod y el servidor LDAP.

Advertencia

Si se establece --ldapTransportSecurity en none, se transmite información en texto plano y posiblemente credenciales entre mongod y el servidor LDAP.

--ldapTimeoutMS <int>

Por defecto: 10000

Disponible solamente en MongoDB Enterprise.

La cantidad de tiempo en milisegundos mongod que debería esperar a que un servidor LDAP responda a una solicitud.

Incrementar el valor de --ldapTimeoutMS puede evitar la falla de conexión entre el servidor MongoDB y el servidor LDAP, si la causa de la falla es un tiempo de espera de conexión. Disminuir el valor de --ldapTimeoutMS reduce el tiempo que MongoDB espera una respuesta del servidor LDAP.

Esta configuración se puede configurar en un mongod en ejecución al utilizar setParameter.

--ldapRetryCount <int>

Nuevo en la versión 6.1.

Por defecto: 0

Disponible solamente en MongoDB Enterprise.

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

--ldapUserToDNMapping <string>

Disponible solamente en MongoDB Enterprise.

Asocia el nombre de usuario proporcionado a mongod para la autenticación con un nombre distinguido (DN) de LDAP. Es posible que deba utilizar --ldapUserToDNMapping para transformar un nombre de usuario en un nombre distinguido de LDAP en los siguientes escenarios:

• Realizar autenticación LDAP con enlace simple de LDAP, donde los usuarios se autentican en MongoDB con nombres de usuario que no son nombres distinguidos completos de LDAP.

• Utilizar una LDAP authorization query template que requiere un nombre distinguido.

• Transformar los nombres de usuario de los clientes que se autentican en MongoDB mediante diferentes mecanismos de autenticación, como x.509 o Kerberos, a un nombre distinguido completo de LDAP para la autorización.

--ldapUserToDNMapping espera una cadena JSON entre comillas que represente un arreglo ordenado de documentos. Cada documento contiene una expresión regular match y una plantilla substitution o ldapQuery utilizada para transformar el nombre de usuario entrante.

Cada documento en el arreglo tiene la siguiente forma:

{
  match: "<regex>"
  substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}

Campo	Descripción	Ejemplo
match	Una expresión regular (regex) con formato ECMAScript para hacer coincidir con un nombre de usuario proporcionado. Cada sección entre paréntesis representa un grupo de captura de regex utilizado por substitution o ldapQuery.	"(.+)ENGINEERING" "(.+)DBA"
substitution	Una plantilla de formato de nombre distinguido (DN) de LDAP que convierte el nombre de autenticación que coincide con la expresión regular match en un DN de LDAP. Cada valor numérico encerrado entre llaves se reemplaza por el grupo de captura de expresión regular correspondiente extraído del nombre de usuario de autenticación mediante la expresión regular match. El resultado de la sustitución debe ser una string escapada RFC4514.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Una plantilla de formato de query LDAP que inserta el nombre de autenticación que coincide con la expresión regular match en un URI de query LDAP codificado respetando el RFC4515 y el RFC4516. Cada valor numérico entre llaves se reemplaza por el grupo de captura de expresión regular correspondiente extraído del nombre de usuario de autenticación mediante la expresión match. mongod ejecuta el query en el servidor LDAP para recuperar el nombre distinguido de LDAP para el usuario autenticado. mongod requiere exactamente un resultado devuelto para que la transformación sea exitosa o mongod omite esta transformación.	"ou=engineering,dc=example, dc=com??one?(user={0})"

Nota

Una explicación de RFC4514, RFC4515, RFC4516, o las consultas LDAP están excluidas de la documentación de MongoDB. Se debe revisar el RFC directamente o usar el recurso LDAP preferido.

Para cada documento del arreglo, debe usar substitution o ldapQuery. No puede especificar ambos en el mismo documento.

Al realizar la autenticación o autorización, mongod recorre cada documento del arreglo en el orden dado, y verifica el nombre de usuario de autenticación contra el filtro match. Si se encuentra una coincidencia, mongod aplica la transformación y utiliza el resultado para autenticar al usuario. mongod no comprueba el resto de los documentos del arreglo.

Si el documento dado no coincide con el nombre de autenticación proporcionado, mongod continúa revisando la lista de documentos para encontrar coincidencias adicionales. Si no se encuentran coincidencias en ningún documento, o si la transformación que el documento describe falla, mongod devuelve un error.

mongod también devuelven un error si una de las transformaciones no puede evaluarse debido a errores de red o de autenticación con el servidor LDAP. mongod rechaza la solicitud de conexión y no verifica los documentos restantes en el arreglo.

A partir de MongoDB 5.0, --ldapUserToDNMapping acepta un string vacío "" o un arreglo vacío [ ] en lugar de un documento de asignación. Si proporciona un string o un arreglo vacío a --ldapUserToDNMapping, MongoDB asigna el nombre de usuario autenticado como el nombre distinguido de LDAP. En versiones anteriores, proporcionar un documento de asignación vacío generaba un error en la asignación.

Ejemplo

A continuación, se muestran dos documentos de transformación. El primer documento coincide con cualquier string que termine en @ENGINEERING, colocando todo lo que preceda al sufijo en un grupo de captura de expresiones regulares. El segundo documento coincide con cualquier string que termine en @DBA, colocando todo lo que preceda al sufijo en un grupo de captura de expresiones regulares.

Importante

Debe pasar el arreglo a --ldapUserToDNMapping como una string.

"[
   {
      match: "(.+)@ENGINEERING.EXAMPLE.COM",
      substitution: "cn={0},ou=engineering,dc=example,dc=com"
   },
   {
      match: "(.+)@DBA.EXAMPLE.COM",
      ldapQuery: "ou=dba,dc=example,dc=com??one?(user={0})"
   }
]"

Un usuario con el nombre de usuario alice@ENGINEERING.EXAMPLE.COM coincide con el primer documento. El grupo de captura de regex {0} corresponde al string alice. La salida resultante es el nombre distinguido "cn=alice,ou=engineering,dc=example,dc=com".

Un usuario con el nombre de usuario bob@DBA.EXAMPLE.COM coincide con el segundo documento. El grupo de captura de expresiones regulares {0} corresponde al string bob. La salida resultante es la query LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongod ejecuta esta query en el servidor LDAP, devolviendo el resultado "cn=bob,ou=dba,dc=example,dc=com".

Si --ldapUserToDNMapping no está configurado, mongod no realiza ninguna transformación al nombre de usuario al intentar autenticar o autorizar a un usuario en el servidor LDAP.

Esta configuración se puede ajustar en un mongod en ejecución al utilizar el comando de base de datos setParameter.

--ldapAuthzQueryTemplate <string>

Disponible solamente en MongoDB Enterprise.

Una URL de query LDAP relativa con formato conforme a RFC4515 y RFC4516 que mongod ejecuta para obtener los grupos LDAP a los que pertenece el usuario autenticado. La query es relativa al host o los hosts especificados en --ldapServers.

En la URL, puede usar los siguientes tokens de sustitución:

Token de sustitución	Descripción
{USER}	Sustituye el nombre de usuario autenticado o el nombre de usuario transformed si se especifica un username mapping.
{PROVIDED_USER}	Sustituye el nombre de usuario proporcionado, es decir, antes de la autenticación o LDAP transformation.

Al crear la URL de consulta, asegúrese de que el orden de los parámetros LDAP respete RFC4516:

[ dn  [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

Si su query incluye un atributo, mongod asume que la query recupera los DNs de los que esta entidad es un nodo.

Si la query no incluye un atributo, mongod se debe asumir que la query recupera todas las entidades de las que el usuario es miembro.

Para cada nombre distinguido de LDAP devuelto por la query, mongod asigna al usuario autorizado un rol correspondiente en la base de datos admin. Si un rol en la base de datos admin coincide exactamente con el nombre distinguido, mongod otorga al usuario los roles y privilegios asignados a ese rol. Consulta el método db.createRole() para obtener más información sobre cómo crear roles.

Ejemplo

Esta query LDAP devuelve cualquier grupo listado en el atributo memberOf del objeto de usuario LDAP.

"{USER}?memberOf?base"

Su configuración LDAP puede no incluir el atributo memberOf como parte del esquema de usuario, puede poseer un atributo diferente para el reporte de la pertenencia a grupos, o puede no rastrear la pertenencia a grupos a través de los atributos. Configure su query con respecto a su propia configuración única de LDAP.

Si no se establece, mongod no puede autorizar a los usuarios usando LDAP.

Esta configuración se puede ajustar en un mongod en ejecución al utilizar el comando de base de datos setParameter.

Nota

Una explicación de RFC4515, RFC4516 o de las queries LDAP está fuera del alcance de la documentación de MongoDB. Se debe revisar el RFC directamente o usar el recurso LDAP preferido.

Opciones de almacenamiento

--storageEngine string

Por defecto: wiredTiger

Especifica el motor de almacenamiento para la base de datos mongod. Los valores disponibles incluyen:

Valor	Descripción
wiredTiger	Para especificar el motor de almacenamiento WiredTiger.
inMemory	Para especificar el Motor de almacenamiento en memoria para implementaciones autogestionadas. Disponible solamente en MongoDB Enterprise.

Si intenta iniciar mongod con un --dbpath que contiene archivos de datos producidos por un motor de almacenamiento distinto al especificado por --storageEngine, mongod no se inicia.

--dbpath <path>

Por defecto: /data/db en Linux y macOS, \data\db en Windows

El directorio donde la instancia mongod almacena sus datos.

Si utiliza el archivo de configuración por defecto incluido con una instalación del administrador de paquetes de MongoDB, la configuración correspondiente storage.dbPath utiliza un valor diferente por defecto.

Los archivos en --dbpath deben corresponder al motor de almacenamiento especificado en --storageEngine. Si los archivos de datos no corresponden a --storageEngine, mongod no se inicia.

--directoryperdb

Utiliza un directorio separado para almacenar los datos de cada base de datos. Los directorios están en el directorio --dbpath, y cada nombre de subdirectorio corresponde al nombre de la base de datos.

No disponible para instancias de mongod que utilizan el motor de almacenamiento en memoria.

A partir de MongoDB 5.0, al eliminar la última colección de una base de datos (o la base de datos misma) cuando --directoryperdb está habilitada, se elimina el subdirectorio recién vaciado de esa base de datos.

Para cambiar la opción --directoryperdb para las implementaciones existentes:

• Para instancias autónomas:

  1. Utilice mongodump en la instancia mongod existente para generar una copia de seguridad.

  2. Detén la instancia mongod.

  3. Agrega el valor --directoryperdb y configura un directorio de datos nuevo

  4. Reinicia la instancia mongod.

  5. Utiliza mongorestore para poblar el nuevo directorio de datos.

• Para set de réplicas:

  1. Detén un miembro secundario.

  2. Agrega el valor --directoryperdb y configura un nuevo directorio de datos para ese miembro secundario.

  3. Reinicia ese secundario.

  4. Utiliza sincronización inicial para poblar el nuevo directorio de datos.

  5. Actualiza los secundarios restantes de la misma manera.

  6. Despromueva el nodo primario y actualice el nodo despromovido de la misma manera.

--syncdelay <value>

Por defecto: 60

Controla cuánto tiempo puede pasar antes de que MongoDB escriba los datos en los archivos de datos.

No establezca este valor en sistemas de producción. En casi todas las situaciones, debería utilizar la configuración por defecto.

El proceso mongod escribe datos muy rápidamente en la bitácora y de manera lenta en los archivos de datos. --syncdelay no tiene efecto en el registro en la bitácora, pero si --syncdelay se establece en 0, la bitácora al final consume todo el espacio disponible en disco.

No disponible para instancias de mongod que utilizan el motor de almacenamiento en memoria.

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.

--upgrade

Actualiza el formato de datos en disco de los archivos especificados por el --dbpath a la última versión, si es necesario.

Esta opción solo afecta la operación de mongod si los archivos de datos están en un formato antiguo.

En la mayoría de los casos no debería fijar este valor, para poder ejercer el mayor control sobre su proceso de actualización. Consulte las notas de versión de MongoDB para obtener más información sobre el proceso de actualización.

--repair

Ejecuta una rutina de reparación en todas las bases de datos para una instancia de mongod.

A partir de MongoDB 5.0:

• La operación de reparación valida las colecciones para encontrar inconsistencias y las corrige si es posible, lo que evita la reconstrucción de los índices.

• Si se recupera el archivo de datos de una colección o si la colección tiene incoherencias que el paso de validación no puede solucionar, entonces se reconstruyen todos los índices.

Tip

Si está ejecutando con el registro en la bitácora habilitado, casi nunca es necesario ejecutar una reparación ya que el servidor puede usar los archivos del registro para restaurar los archivos de datos a un estado limpio automáticamente. Sin embargo, es posible que deba ejecutar una reparación en los casos en que necesite recuperarse de una corrupción de datos a nivel de disco.

Advertencia

• Utilice mongod --repair solo si no tiene otras opciones. La operación remueve y no guarda ningún dato corrupto durante el proceso de reparación.

• Evite ejecutar --repair en un nodo del set de réplicas:

  • Para reparar un nodo de un set de réplicas, si tiene una copia intacta de sus datos disponible (por ejemplo, una copia de seguridad reciente o un nodo intacto del set de réplicas), restaure desde esa copia intacta. Para obtener más información, consulte Resincronizar un nodo de un set de réplicas autogestionado.

  • Si decide ejecutar mongod --repair contra un nodo del set de réplicas y la operación modifica los datos o los metadatos, debe realizar una resincronización completa para que el nodo vuelva a unirse al set de réplicas.

• Antes de utilizar --repair, haga una copia de seguridad del directorio dbpath.

• Si la reparación no se completa por algún motivo, debe reiniciar la instancia mediante la opción --repair.

--journalCommitInterval <value>

Por defecto: 100

El tiempo máximo en milisegundos que permite el proceso mongod entre operaciones de registro en la bitácora. Los valores pueden variar de 1 a 500 milisegundos. Los valores más bajos aumentan la durabilidad de la bitácora, a expensas del rendimiento del disco.

En WiredTiger, el intervalo de confirmación por defecto de la bitácora es de 100 milisegundos. Una escritura que incluya o implique que j:true provoca una sincronización inmediata del registro en la bitácora. Para obtener detalles y condiciones adicionales que afectan la frecuencia con la que se sincroniza, consulta el Proceso de registro en la bitácora.

No disponible para instancias de mongod que utilizan el motor de almacenamiento en memoria.

Opciones de WiredTiger

--wiredTigerCacheSizeGB <float>

Define el tamaño máximo de la caché interna que WiredTiger utiliza para todos los datos. La memoria que consume la creación de índices (consulte maxIndexBuildMemoryUsageMegabytes) es independiente de la memoria caché de WiredTiger.

Los valores pueden variar entre 0.25 GB y 10000 GB.

Configuración de caché

El tamaño de caché interno por defecto de WiredTiger es el mayor de los siguientes:

• 50% de (RAM - 1GB), o

• 0.256 GB.

Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger usa 1.5GB de RAM (0.5 * (4GB - 1GB) = 1.5 GB). Al proporcionar un tamaño de caché específico, asegúrese de que la RAM no supere los límites de 0.256GB a 10000GB.

Evite aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado. Si su caso lo requiere, puede usar --wiredTigerCacheSizePct para tener en cuenta los cambios en la memoria debidos a la vertical. Debe especificar un porcentaje de hasta el 80% de la memoria disponible. Los valores calculados pueden variar entre 0.256GB y 10000GB. Por ejemplo, en un sistema con 2GB de RAM, --wiredTigerCacheSizePct no se puede establecer en 10 porque el 10% de 2GB es 0.2 GB, que es menor que 0.256GB.

Nota

En algunos casos, como al ejecutarse en un contenedor configurado para usar menos RAM que la memoria asignada al host, es necesario tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger con un valor adecuado, ya que WiredTiger podría no tener en cuenta los límites de memoria del contenedor específico en ciertos casos.

Para ver, el valor que WiredTiger utiliza como memory limit hostInfo la cantidad máxima de RAM disponible, utilice el comando.

Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.

Con la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no está siendo utilizada por la caché de WiredTiger ni por otros procesos.

Nota

El --wiredTigerCacheSizeGB limita el tamaño de la caché interna de WiredTiger. El sistema operativo utiliza la memoria libre disponible para la caché del sistema de archivos, lo que permite que los archivos de datos comprimidos de MongoDB permanezcan en la memoria. Además, el sistema operativo utiliza cualquier RAM libre para almacenar en búfer los bloques del sistema de archivos y la caché del sistema de archivos.

Para acomodar a los consumidores adicionales de RAM, es posible que debas reducir el tamaño de la caché interna de WiredTiger.

El valor predeterminado del tamaño de la caché interna de WiredTiger asume que hay una sola instancia mongod por máquina. Si una sola máquina contiene varias instancias de MongoDB, entonces se debe disminuir la configuración para dar cabida a las otras instancias mongod.

Si ejecuta mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debe establecer --wiredTigerCacheSizeGB en un valor inferior a la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los otros procesos que se ejecutan en el contenedor. Consulte memLimitMB.

--wiredTigerCacheSizePct <float>

Define la cantidad máxima de memoria que se puede asignar para la caché como un porcentaje de la RAM física. La memoria que consume la creación de índices (consulta maxIndexBuildMemoryUsageMegabytes) es independiente de la memoria caché de WiredTiger.

Puedes especificar un porcentaje de hasta un 80 % de la memoria disponible. El rango varía de 0.25 GB a 10000 GB.

Configuración de caché

El tamaño de caché interno por defecto de WiredTiger es el mayor de los siguientes:

• 50% de (RAM - 1GB), o

• 0.256 GB.

Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger usa 1.5GB de RAM (0.5 * (4GB - 1GB) = 1.5 GB). Al proporcionar un tamaño de caché específico, asegúrese de que la RAM no supere los límites de 0.256GB a 10000GB.

Evite aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado. Si su caso lo requiere, puede usar --wiredTigerCacheSizePct para tener en cuenta los cambios en la memoria debidos a la vertical. Debe especificar un porcentaje de hasta el 80% de la memoria disponible. Los valores calculados pueden variar entre 0.256GB y 10000GB. Por ejemplo, en un sistema con 2GB de RAM, --wiredTigerCacheSizePct no se puede establecer en 10 porque el 10% de 2GB es 0.2 GB, que es menor que 0.256GB.

Nota

En algunos casos, como al ejecutarse en un contenedor configurado para usar menos RAM que la memoria asignada al host, es necesario tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger con un valor adecuado, ya que WiredTiger podría no tener en cuenta los límites de memoria del contenedor específico en ciertos casos.

Para ver, el valor que WiredTiger utiliza como memory limit hostInfo la cantidad máxima de RAM disponible, utilice el comando.

Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.

Con la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no está siendo utilizada por la caché de WiredTiger ni por otros procesos.

Nota

El --wiredTigerCacheSizeGB limita el tamaño de la caché interna de WiredTiger. El sistema operativo utiliza la memoria libre disponible para la caché del sistema de archivos, lo que permite que los archivos de datos comprimidos de MongoDB permanezcan en la memoria. Además, el sistema operativo utiliza cualquier RAM libre para almacenar en búfer los bloques del sistema de archivos y la caché del sistema de archivos.

Para acomodar a los consumidores adicionales de RAM, es posible que debas reducir el tamaño de la caché interna de WiredTiger.

El valor predeterminado del tamaño de la caché interna de WiredTiger asume que hay una sola instancia mongod por máquina. Si una sola máquina contiene varias instancias de MongoDB, entonces se debe disminuir la configuración para dar cabida a las otras instancias mongod.

Si ejecuta mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debe establecer --wiredTigerCacheSizeGB en un valor inferior a la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los otros procesos que se ejecutan en el contenedor. Consulte memLimitMB.

--wiredTigerJournalCompressor <compressor>

Por defecto: snappy

Especifica el tipo de compresión que se debe usar para comprimir los datos de registro en la bitácora de WiredTiger.

Los compresores disponibles son:

• none

• rápido

• zlib

• zstd

--wiredTigerDirectoryForIndexes

Cuando inicia mongod con --wiredTigerDirectoryForIndexes, mongod almacena índices y colecciones en subdirectorios separados en el directorio de datos (es decir, --dbpath). Específicamente, mongod almacena los índices en un subdirectorio llamado index y los datos de la colección en un subdirectorio llamado collection.

Al utilizar un enlace simbólico, puede especificar una ubicación diferente para los índices. Específicamente, cuando la instancia mongod no esté en ejecución, mueva el subdirectorio index al destino y cree un enlace simbólico llamado index en el directorio de datos hacia el nuevo destino.

--wiredTigerCollectionBlockCompressor <compressor>

Por defecto: snappy

Especifica la compresión por defecto para los datos de la colección. Puede anular esto por colección al crear colecciones.

Los compresores disponibles son:

• none

• rápido

• zlib

• zstd

--wiredTigerCollectionBlockCompressor afecta a todas las colecciones creadas. Si cambia el valor de --wiredTigerCollectionBlockCompressor en una implementación existente de MongoDB, todas las nuevas colecciones utilizarán el compresor especificado. Las colecciones existentes continúan utilizando el compresor especificado cuando se crearon, o el compresor por defecto en ese momento.

--wiredTigerIndexPrefixCompression <boolean>

Por defecto: true

Habilita o deshabilita Reducción de prefijo para los datos de índice.

Especifica true para --wiredTigerIndexPrefixCompression para activar la reducción de prefijos para los datos de índice, o false para desactivar la reducción de prefijos para los datos de índice.

La configuración de --wiredTigerIndexPrefixCompression afecta a todos los índices creados. Si cambia el valor de --wiredTigerIndexPrefixCompression en una implementación de MongoDB existente, todos los índices nuevos utilizarán la Reducción de prefijo. Los índices existentes no se ven afectados.

Opciones de replicación

--replSet <setname>

Configura la replicación. Especifique un nombre de set de réplicas como argumento para este conjunto. Todos los hosts en el set de réplicas deben tener el mismo nombre del conjunto.

Si la aplicación se conecta a más de un set de réplicas, cada set debe tener un nombre distinto. Algunos drivers agrupan las conexiones del set de réplicas por nombre del set de réplicas.

--oplogSize <value>

El tamaño máximo en megabytes para el OpLog. La configuración oplogSize establece el tamaño sin comprimir del oplog, no el tamaño en disco.

Nota

El oplog puede crecer más allá de su límite de tamaño configurado para evitar borrar el majority commit point.

Por defecto, el proceso mongod crea un oplog basado en la cantidad máxima de espacio disponible. Para los sistemas de 64 bits, el OpLog suele representar el 5 % del espacio disponible en el disco.

Una vez que el mongod haya creado el oplog por primera vez, cambiar la opción --oplogSize no afecta el tamaño del oplog. Para cambiar el período mínimo de retención del oplog después de iniciar el mongod, utilice replSetResizeOplog. replSetResizeOplog le permite redimensionar el oplog dinámicamente sin reiniciar el proceso mongod. Para que los cambios realizados con replSetResizeOplog persistan tras un reinicio, actualice el valor de --oplogSize.

Consulta Tamaño del Oplog para obtener más información.

--oplogMinRetentionHours <value>

Especifica el número mínimo de horas para preservar una entrada de OpLog, donde los valores decimales representan las fracciones de una hora. Por ejemplo, un valor de 1.5 representa una hora y treinta minutos.

El valor debe ser mayor o igual a 0. Un valor de 0 indica que mongod debe truncar el oplog comenzando con las entradas más antiguas para mantener el tamaño máximo del oplog configurado.

Se establece por defecto en 0.

Un mongod iniciado con --oplogMinRetentionHours solo puede remover una entrada de oplog si:

• El oplog ha alcanzado el tamaño de oplog máximo configurado y

• La entrada del oplog es más antigua que el número de horas configurado según el reloj del sistema del host.

El mongod tiene el siguiente comportamiento cuando se configura con un período mínimo de retención de oplog:

• El oplog puede crecer sin restricciones para retener las entradas del oplog durante el número de horas configurado. Esto puede resultar en la reducción o el agotamiento del espacio en disco del sistema debido a una combinación de un alto volumen de guardado y un largo período de retención.

• Si el oplog crece más allá de su tamaño máximo, el mongod puede seguir manteniendo ese espacio en disco incluso si el oplog vuelve a su tamaño máximo o se configura para un tamaño máximo menor. Consulte La reducción del tamaño del Oplog no devuelve inmediatamente el espacio en disco.

• El mongod compara el reloj de pared del sistema con la hora de creación de una entrada de oplog al aplicar la retención de entradas de oplog. El desfase horario entre los componentes del clúster puede resultar en un comportamiento inesperado de retención del oplog. Consulte la sincronización del reloj para obtener más información sobre esta sincronización entre los miembros del clúster.

Para cambiar el período mínimo de retención de oplog tras iniciar el mongod, utilice replSetResizeOplog. replSetResizeOplog le permite redimensionar el oplog dinámicamente sin reiniciar el proceso de mongod. Para que los cambios realizados con replSetResizeOplog persistan tras un reinicio, actualice el valor de --oplogMinRetentionHours.

--enableMajorityReadConcern

Por defecto: true

Configura el soporte para el nivel de consistencia de lectura "majority".

A partir de MongoDB 5.0, --enableMajorityReadConcern no se puede cambiar y siempre se establece en true. En versiones anteriores de MongoDB, --enableMajorityReadConcern era configurable.

Advertencia

Si está utilizando una arquitectura de tres nodos de primario-secundario-árbitro (PSA), considere lo siguiente:

• El nivel de confirmación de escritura "majority" puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulta Mitigar problemas de rendimiento con un set de réplicas de PSA autogestionado.

• Si estás utilizando un "majority" global por defecto y el nivel de confirmación de escritura es menor que el tamaño de la mayoría, tus consultas pueden devolver datos obsoletos (no completamente replicados).

Opciones de clúster fragmentado

--configsvr

Es obligatorio si se inicia un servidor de configuración.

Declara que esta instancia mongod sirve como servidor de configuración de un clúster particionado. Al ejecutarlo con esta opción, los clientes (es decir, otros componentes del clúster) no pueden guardar datos en ninguna base de datos que no sea config y admin. El puerto por defecto para un mongod con esta opción es 27019 y el directorio --dbpath por defecto es /data/configdb, a menos que se especifique.

Importante

Al iniciar un servidor MongoDB con --configsvr, también debes especificar un --replSet.

El uso de las instancias obsoletas de mongod espejadas como servidores de configuración (SCCC) ya no es compatible.

Los servidores de configuración del Set de réplicas (CSRS) deben ejecutar el motor de almacenamiento WiredTiger.

La opción --configsvr crea un oplog local.

No utilices la opción --configsvr junto con --shardsvr. Los servidores de configuración no pueden ser servidores de partición.

No utilice el --configsvr con el parámetro skipShardingConfigurationChecks. Es decir, si está iniciando temporalmente el mongod como una instancia autónoma para operaciones de mantenimiento, incluya el parámetro skipShardingConfigurationChecks y excluya --configsvr. Una vez que se haya completado el mantenimiento, remueva el parámetro skipShardingConfigurationChecks y reinicie con --configsvr.

--shardsvr

Requerido si se inicia un servidor de partición.

Configura esta instancia mongod como una partición en un clúster particionado. El puerto por defecto para estas instancias es 27018.

Importante

Al iniciar un servidor MongoDB con --shardsvr, también debes especificar un --replSet.

No utilice el --shardsvr con el parámetro skipShardingConfigurationChecks. Es decir, si está iniciando temporalmente el mongod como una instancia autónoma para operaciones de mantenimiento, incluya el parámetro skipShardingConfigurationChecks y excluya --shardsvr. Una vez que se haya completado el mantenimiento, remueva el parámetro skipShardingConfigurationChecks y reinicie con --shardsvr.

--moveParanoia

Si se especifica, durante la migración de fragmentos, un fragmento guarda, en el directorio moveChunk del --dbpath, todos los documentos migrados desde ese fragmento.

MongoDB no elimina automáticamente los datos guardados en el directorio moveChunk.

--noMoveParanoia

Durante la migración de fragmentos, una partición no guarda los documentos migrados desde sí misma.

Este es el comportamiento por defecto.

Opciones de TLS

--tlsMode <mode>

Habilita el uso de TLS para todas las conexiones de red. El argumento de la opción --tlsMode puede ser uno de los siguientes:

Valor	Descripción
disabled	El servidor no usa TLS.
allowTLS	Las conexiones entre servidores no emplean TLS. Para las conexiones entrantes, el servidor acepta tanto TLS como conexiones no TLS.
preferTLS	Las conexiones entre servidores utilizan TLS. Para las conexiones entrantes, el servidor acepta tanto TLS como conexiones no TLS.
requireTLS	El servidor utiliza y acepta únicamente conexiones cifradas mediante TLS.

Si no se especifica --tlsCAFile o tls.CAFile, y no estás utilizando la autenticación X.509, debes establecer el parámetro tlsUseSystemCA en true. Esto hace que MongoDB utilice el almacén de certificados de CA de todo el sistema al conectarse a un servidor con TLS activado.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

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

--tlsCertificateKeyFile <filename>

Especifica el archivo .pem que contiene tanto el certificado TLS como la clave.

En macOS o Windows, puedes utilizar la opción --tlsCertificateSelector para especificar un certificado de los almacenes de certificados del sistema operativo en lugar de un archivo de clave PEM. --tlsCertificateKeyFile y --tlsCertificateSelector son opciones mutuamente excluyentes. Solo puedes especificar uno.

• En Linux/BSD, debe especificar --tlsCertificateKeyFile cuando TLS/SSL está habilitado.

• En Windows o macOS, debe especificar --tlsCertificateKeyFile o --tlsCertificateSelector cuando TLS/SSL está habilitado.

  Importante

  Para Windows solamente, MongoDB no admite archivos PEM cifrados. El mongod no se inicia si encuentra un archivo PEM cifrado. Para almacenar y acceder de forma segura a un certificado para su uso con TLS en Windows, use --tlsCertificateSelector.

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

--tlsCertificateKeyFilePassword <value>

Especifica la contraseña para descifrar el archivo de clave del certificado (es decir, --tlsCertificateKeyFile). Utilice la opción --tlsCertificateKeyFilePassword solo si el archivo de clave del certificado está cifrado. En todos los casos, el mongod elimina la contraseña de todos los registros y reportes de salida.

• En Linux/BSD, si la llave privada en el archivo PEM está cifrada y no se especifica la opción --tlsCertificateKeyFilePassword, MongoDB solicitará una frase de contraseña. Se debe consultar la frase de contraseña del certificado TLS/SSL.

• En macOS, si la llave privada del archivo PEM está cifrada, debe especificar explícitamente la opción --tlsCertificateKeyFilePassword. Alternativamente, puede usar un certificado del almacén seguro del sistema (consulte --tlsCertificateSelector) en lugar de un archivo PEM o usar un archivo PEM sin cifrar.

• En Windows, MongoDB no admite certificados cifrados. El mongod falla si encuentra un archivo PEM cifrado. Utiliza --tlsCertificateSelector en su lugar.

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

--clusterAuthMode <option>

Por defecto: archivo de clave

El modo de autenticación utilizado para la autenticación del clúster. Si utilizas autenticación interna de X.509, especifícalo aquí. Esta opción puede tener uno de los siguientes valores:

Valor	Descripción
keyFile	Utilice un archivo de clave para la autenticación. Acepte únicamente archivos de clave.
sendKeyFile	Para actualizaciones continuas. Envía un archivo de claves para la autenticación, pero acepta tanto archivos de claves como certificados X.509.
sendX509	Para actualizaciones continuas. Envía el certificado X.509 para la autenticación, pero acepta tanto archivos de claves como certificados X.509.
x509	Opción recomendada. Envía el certificado X.509 para la autenticación y acepta solo certificados X.509.

Si no se especifica --tlsCAFile o tls.CAFile, y no estás utilizando la autenticación X.509, debes establecer el parámetro tlsUseSystemCA en true. Esto hace que MongoDB utilice el almacén de certificados de CA de todo el sistema al conectarse a un servidor con TLS activado.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

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

--tlsClusterFile <filename>

Especifica el archivo .pem que contiene el archivo de llave de certificado X.509 para la autenticación de membresía del clúster o el set de réplicas.

En macOS o Windows, puedes utilizar la opción --tlsClusterCertificateSelector para especificar un certificado de los almacenes de certificados del sistema operativo en lugar de un archivo de clave PEM. --tlsClusterFile y --tlsClusterCertificateSelector son opciones mutuamente excluyentes. Solo puedes especificar uno.

Si --tlsClusterFile no especifica el archivo .pem para la autenticación interna del clúster o la alternativa --tlsClusterCertificateSelector, el clúster utiliza el archivo .pem especificado en la opción --tlsCertificateKeyFile o el certificado devuelto por el --tlsCertificateSelector.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

mongod / mongos registra una advertencia en la conexión si el certificado X.509 presentado caduca dentro de 30 días a partir de la hora del sistema host mongod/mongos.

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

Importante

Solo para Windows, MongoDB no brinda soporte a archivos PEM cifrados. El mongod no se inicia si encuentra un archivo PEM cifrado. Para almacenar y acceder de forma segura a un certificado para usar con la autenticación de membresía en Windows, utiliza --tlsClusterCertificateSelector.

--tlsCertificateSelector <parameter>=<value>

Nota

Disponible en Windows y macOS como alternativa a --tlsCertificateKeyFile.

Especifica una propiedad del certificado para seleccionar un certificado coincidente con los almacenes de certificados del sistema operativo para usar en TLS.

Las opciones --tlsCertificateKeyFile y --tlsCertificateSelector son mutuamente excluyentes. Solo puedes especificar uno.

--tlsCertificateSelector acepta un argumento en el formato <property>=<value> donde la propiedad puede ser una de las siguientes:

Propiedad	Tipo de valor	Descripción
subject	string ASCII	Nombre del sujeto o nombre común en el certificado
thumbprint	cadena hexadecimal	Una secuencia de bytes, expresada en hexadecimal, utilizada para identificar una llave pública mediante su resumen SHA-1. El thumbprint a veces se conoce como fingerprint.

Al utilizar el almacén de certificados SSL del sistema, se emplea OCSP (Protocolo de estado de certificados en línea) para validar el estado de revocación de los certificados.

El mongod busca en el almacén seguro de certificados del sistema operativo los certificados de CA necesarios para validar toda la cadena de certificados del certificado TLS indicado. Específicamente, el almacén seguro de certificados debe incluir la CA raíz y cualquier certificado de CA intermedio necesario para compilar toda la cadena de certificados hasta el certificado TLS. No utiliza --tlsCAFile ni --tlsClusterCAFile para especificar el certificado de CA raíz e intermedio

Por ejemplo, si el certificado TLS/SSL se firmó con un único certificado de CA raíz, el almacén seguro de certificados debe contener ese certificado de CA raíz. Si el certificado TLS/SSL se firmó con un certificado de CA intermedia, el almacén seguro de certificados debe contener el certificado de CA intermedia y el certificado de CA raíz.

Nota

No puede usar el comando rotateCertificates o el método shell db.rotateCertificates() cuando utiliza net.tls.certificateSelector o --tlsCertificateSelector configurado en thumbprint

--tlsClusterCertificateSelector <parameter>=<value>

Nota

Disponible en Windows y macOS como alternativa a --tlsClusterFile.

Especifica una propiedad de certificado para seleccionar un certificado que coincida con el almacén de certificados del sistema operativo para la autenticación interna de miembros X.509.

--tlsClusterFile y --tlsClusterCertificateSelector son opciones mutuamente excluyentes. Solo puedes especificar uno.

--tlsClusterCertificateSelector acepta un argumento en el formato <property>=<value> donde la propiedad puede ser una de las siguientes:

Propiedad	Tipo de valor	Descripción
subject	string ASCII	Nombre del sujeto o nombre común en el certificado
thumbprint	cadena hexadecimal	Una secuencia de bytes, expresada en hexadecimal, utilizada para identificar una llave pública mediante su resumen SHA-1. El thumbprint a veces se conoce como fingerprint.

mongod busca en el almacén seguro de certificados del sistema operativo los certificados de la CA necesarios para validar por completo la cadena de certificados del certificado de clúster especificado. Específicamente, el almacén seguro de certificados debe incluir la CA raíz y cualquier certificado de CA intermedio necesario para compilar toda la cadena de certificados hasta el certificado del clúster. No utilices --tlsCAFile o --tlsClusterCAFile para especificar el certificado de CA raíz e intermedio.

Por ejemplo, si el certificado del clúster se firmó con un certificado de CA raíz única, el almacén seguro de certificados debe contener ese certificado de CA raíz. Si el certificado del clúster se firmó con un certificado de CA intermedia, el almacén seguro de certificados debe contener el certificado de CA intermedia y el certificado de CA raíz.

mongod / mongos registra una advertencia en la conexión si el certificado X.509 presentado caduca dentro de 30 días a partir de la hora del sistema host mongod/mongos.

--tlsClusterPassword <value>

Especifique la contraseña para desencriptar el archivo de clave de certificado X.509 especificado con --tlsClusterFile. Utilice la opción --tlsClusterPassword solo si el archivo de clave del certificado está cifrado. En todos los casos, el mongod elimina la contraseña de todos los registros y reportes de salida.

• En Linux/BSD, si la llave privada en el archivo X.509 está cifrada y no especificas la opción --tlsClusterPassword, MongoDB solicita una frase de contraseña. Consulta Frase de contraseña del certificado TLS/SSL.

• En macOS, si la llave privada del archivo X.509 está cifrada, debes especificar explícitamente la opción --tlsClusterPassword. Alternativamente, también puedes usar un certificado del almacén seguro del sistema (consulta --tlsClusterCertificateSelector) en lugar de un archivo PEM del clúster o usar un archivo PEM sin cifrar.

• En Windows, MongoDB no admite certificados cifrados. El mongod falla si encuentra un archivo PEM cifrado. Utiliza --tlsClusterCertificateSelector en su lugar.

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

--tlsCAFile <filename>

Especifica el archivo .pem que contiene la cadena de certificados raíz de la Autoridad Certificadora. Especifica el nombre del archivo .pem con rutas relativas o absolutas.

Importante

Al iniciar una mongod instancia con TLS/SSL habilitado, debe 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.

Solo para Windows/macOS

Si utilizas --tlsCertificateSelector y/o --tlsClusterCertificateSelector, no utiliza --tlsCAFile para especificar los certificados CA raíz e intermedios. Almacena todos los certificados de CA necesarios para validar la cadena de confianza completa de los certificados --tlsCertificateSelector y/o --tlsClusterCertificateSelector en el almacén seguro de certificados.

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

--tlsClusterCAFile <filename>

Especifica el archivo .pem que contiene la cadena de certificados raíz de la Autoridad de Certificación utilizada para validar el certificado presentado por un cliente que establece una conexión. Especifique el nombre del archivo .pem utilizando rutas relativas o absolutas. --tlsClusterCAFile requiere que --tlsCAFile esté configurado.

Si --tlsClusterCAFile no especifica el archivo .pem para validar el certificado de un cliente que establece una conexión, el clúster utiliza el archivo .pem especificado en la opción --tlsCAFile.

--tlsClusterCAFile le permite utilizar autoridades de certificación independientes para verificar las partes del protocolo de enlace TLS de cliente a servidor y de servidor a cliente.

Solo para Windows/macOS

Si utilizas --tlsCertificateSelector y/o --tlsClusterCertificateSelector, no utiliza --tlsClusterCAFile para especificar los certificados CA raíz e intermedios. Almacena todos los certificados de CA necesarios para validar la cadena de confianza completa de los certificados --tlsCertificateSelector y/o --tlsClusterCertificateSelector en el almacén seguro de certificados.

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

--tlsCRLFile <filename>

Especifica el archivo .pem que contiene la Lista de revocación de certificados. Especifica el nombre del archivo .pem con rutas relativas o absolutas.

Nota

• No puedes especificar un archivo CRL en macOS. En su lugar, puedes utilizar el almacén de certificados SSL del sistema, que emplea OCSP (Protocolo de Estado de Certificados en linea) para validar el estado de revocación de los certificados. Consulta --tlsCertificateSelector para utilizar el almacén de certificados SSL del sistema.

• Para verificar la revocación de certificados, MongoDB enables utiliza OCSP (Protocolo de Estado de Certificados en línea) por defecto como alternativa a especificar un archivo CRL o usar los almacenes de certificados SSL del sistema.

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

--tlsAllowInvalidCertificates

Evita las comprobaciones de validación de los certificados TLS en otros servidores del clúster y permite el uso de certificados no válidos para conectarse.

Nota

Si especificas --tlsAllowInvalidCertificates o tls.allowInvalidCertificates: true al utilizar la autenticación X.509, un certificado no válido es suficiente solo para establecer una conexión TLS, pero es insuficiente para la autenticación.

Al utilizar la configuración de --tlsAllowInvalidCertificates, MongoDB registra una advertencia sobre el uso del certificado no válido.

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

--tlsAllowInvalidHostnames

Desactiva la validación de los nombres de host en los certificados TLS al conectarse a otros nodos del set de réplicas o del clúster para la autenticación entre procesos. Esto permite que mongod se conecte a otros nodos si los nombres de host en sus certificados no coinciden con su nombre de host configurado.

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

--tlsAllowConnectionsWithoutCertificates

Por defecto, el servidor omite la validación del certificado del cliente a menos que esté configurado para utilizar un archivo de la Autoridad de Certificación (CA). Si se proporciona un archivo de CA, se aplican las siguientes reglas:

• Para clientes que no proporcionan certificados, mongod o mongos cifra la conexión TLS/SSL, suponiendo que la conexión se realice correctamente.

• Para los clientes que presentan un certificado, mongod realiza la validación del certificado mediante la cadena de certificados raíz especificada por --tlsCAFile y rechaza a los clientes con certificados no válidos.

Utiliza la opción --tlsAllowConnectionsWithoutCertificates si tienes una implementación mixta que incluya clientes que no presentan o no pueden presentar certificados al mongod.

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

--tlsDisabledProtocols <protocol(s)>

Impide que un servidor MongoDB que se ejecute con TLS acepte conexiones entrantes que utilicen un protocolo o protocolos específicos. Para especificar varios protocolos, utiliza una lista de protocolos separada por comas.

--tlsDisabledProtocols reconoce los siguientes protocolos: TLS1_0, TLS1_1, TLS1_2 y TLS1_3.

• En macOS, no puedes desactivar TLS1_1 y dejar TLS1_0 y TLS1_2 activados. Debes desactivar al menos uno de los otros dos, por ejemplo, TLS1_0,TLS1_1.

• Para enumerar varios protocolos, especifíquelos como una lista de protocolos separados por comas. Por ejemplo TLS1_0,TLS1_1.

• Especificar un protocolo no reconocido impide que el servidor se inicie.

• Los protocolos deshabilitados especificados anulan cualquier protocolo deshabilitado por defecto.

MongoDB desactiva el uso de TLS 1.0, si TLS 1.1+ está disponible en el sistema. Para habilitar el TLS deshabilitado 1.0, especificanone para --tlsDisabledProtocols.

Los nodos de los sets de réplicas y los clústeres fragmentados deben tener al menos un protocolo en común.

Tip

Prohibir protocolos

--tlsFIPSMode

Indica al mongod que utilice el modo FIPS de la librería TLS. Su sistema debe tener una librería compatible con FIPS para usar la opción --tlsFIPSMode.

Nota

TLS/SSL compatible con FIPS está disponible solo en MongoDB Enterprise. Ve Configurar MongoDB para FIPS si deseas obtener más información.

Opciones del perfilador

--profile <level>

Por defecto: 0

Configura el nivel del perfilador de la base de datos. Los siguientes niveles de perfilador están disponibles:

0

El perfilador está desactivado y no recopila ningún dato. Este es el nivel por defecto del perfilador.

1

El generador de perfiles recopila datos de las operaciones que toman más tiempo que el valor de slowms o que coinciden con un filtro.

Cuando se establece un filtro:

• Las opciones slowms y sampleRate no se utilizan para el perfilado.

• El perfilador solo captura las operaciones que coinciden con el filtro.

2

El perfilador recopila datos de todas las operaciones. Cuando se establece en el nivel 2, el perfilador ignora los valores proporcionados por el usuario para slowms y filter.

Advertencia

El perfilado puede degradar el rendimiento y exponer datos de la consulta no cifrados en el registro del sistema. Considera detenidamente cualquier implicación de rendimiento y seguridad antes de configurar y activar el perfilador en una implementación de producción.

Consulte Sobrecarga del perfilador para obtener más información sobre la posible degradación del rendimiento.

--slowms <integer>

Por defecto: 100

El umbral de tiempo de operación lenta, en milisegundos. Las operaciones que se ejecutan durante más tiempo que este umbral se consideran lentas.

Cuando logLevel se establece en 0, MongoDB registra las operaciones lentas en el registro de diagnóstico a una tasa determinada por slowOpSampleRate.

Con configuraciones más altas de logLevel, todas las operaciones aparecen en el registro de diagnóstico independientemente de su latencia, con la siguiente excepción: el registro de mensajes de entrada de oplog lentos por parte de los secundarios. Los secundarios solo registran las entradas de oplog lentas; aumentar el logLevel no registra todas las entradas de oplog.

Para las instancias de mongod, --slowms afecta al registro de diagnóstico y, si está activado, al perfilador.

Tip

Database Profiler

--slowOpSampleRate <double>

Por defecto: 1.0

La fracción de operaciones lentas que se deben perfilar o registrar. --slowOpSampleRate acepta valores entre 0 y 1, inclusive.

--slowOpSampleRate no afecta el registro de entradas lentas del oplog que realizan los miembros secundarios de un set de réplicas. Los miembros secundarios registran todas las entradas del oplog que tardan más que el umbral de operación lenta, independientemente del --slowOpSampleRate

Para las instancias de mongod, --slowOpSampleRate afecta al registro de diagnóstico y, si está activado, al perfilador.

Opciones de auditoría

--auditCompressionMode

Novedades en la versión 5.3.

Especifica el modo de compresión para el cifrado de registros de auditoría. Debes también habilitar el cifrado del registro de auditoría con --auditEncryptionKeyUID o --auditLocalKeyFile.

--auditCompressionMode puede configurarse en uno de estos valores:

Valor	Descripción
zstd	Utiliza el algoritmo zstd para comprimir el registro de auditoría.
none (por defecto)	No comprimas el registro de auditoría.

Nota

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

--auditDestination

Permite auditar y especifica dónde mongod envía todos los eventos de auditoría.

--auditDestination puede tener uno de los siguientes valores:

Valor	Descripción
syslog	Registra los eventos de auditoría en syslog en formato JSON. No está disponible en Windows. Los mensajes de auditoría tienen un nivel de severidad syslog de info y un nivel de facilidad de user. El límite de mensajes de syslog puede resultar en el truncamiento de los mensajes de auditoría. El sistema de auditoría no detecta ni el truncamiento ni los errores cuando ocurren.
console	Genera los eventos de auditoría en stdout en formato JSON.
file	Exporta los eventos de auditoría al archivo especificado en --auditPath en el formato especificado en --auditFormat.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditEncryptionKeyUID

Novedades en la versión 6.0.

Especifica el identificador único de la clave del Protocolo de Interoperabilidad de Gestión de Claves (KMIP) para el cifrado del registro de auditoría.

No puede usar --auditEncryptionKeyUID y --auditLocalKeyFile al mismo tiempo.

Nota

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

--auditFormat

Especifica el formato del archivo de salida para auditoría si --auditDestination es file. La opción --auditFormat puede tener uno de los siguientes valores:

Valor	Descripción
JSON	Exporta los eventos de auditoría en formato JSON al archivo especificado en --auditPath.
BSON	Exporta los eventos de auditoría en formato binario BSON en el archivo especificado en --auditPath.

La impresión de eventos de auditoría en un archivo en formato JSON degrada el rendimiento del servidor más que imprimirlos en un archivo en formato BSON.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditLocalKeyFile

Novedades en la versión 5.3.

Especifica la ruta y el nombre de archivo para un archivo de clave de auditoría local para el cifrado del registro de auditoría.

Nota

Utilice --auditLocalKeyFile solo para pruebas porque la clave no está segura. Para asegurar la clave, utilice --auditEncryptionKeyUID y un servidor externo del Protocolo de Interoperabilidad de Gestión de Claves (KMIP).

No puede usar --auditLocalKeyFile y --auditEncryptionKeyUID al mismo tiempo.

Nota

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

--auditPath

Especifica el archivo de salida para la auditoría si --auditDestination tiene un valor de file. La opción --auditPath puede aceptar un nombre de ruta completo o un nombre de ruta relativa.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditFilter

Especifica el filtro para limitar los tipos de operaciones que el sistema de auditoría registra. La opción toma una representación en forma de string de un documento de query del tipo:

{ <field1>: <expression1>, ... }

El <field> puede ser cualquier campo en el mensaje de auditoría, incluidos los campos devueltos en el documento param. La <expression> es una expresión de condición de query.

Para especificar un filtro de auditoría, encierre el documento del filtro entre comillas simples para pasarlo como un string.

Para especificar el filtro de auditoría en un archivo de configuración, debe utilizar el formato YAML del archivo de configuración.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

Opciones inMemory

--inMemorySizeGB <float>

Por defecto: 50 % de la RAM física menos 1 GB.

Cantidad máxima de memoria a asignar para los datos del motor de almacenamiento en memoria, incluidos los índices, el oplog (si el mongod forma parte de un set de réplicas), los metadatos del clúster, etc.

Los valores pueden estar en un rango de 256 MB a 10 TB y pueden ser de tipo flotante.

Por defecto, el motor de almacenamiento en memoria utiliza el 50% de la RAM física menos 1 GB.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

Opciones de gestión de llaves de cifrado

--enableEncryption

Por defecto: false

Permite el cifrado para el motor de almacenamiento WiredTiger. Esta opción debe estar habilitada para poder pasar las llaves de cifrado y configuraciones.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--encryptionCipherMode <string>

Por defecto: AES256-CBC

El modo de cifrado a utilizar para el cifrado en reposo:

Modo	Descripción
AES256-CBC	Estándar de cifrado avanzado de 256 bits en modo de encadenamiento de bloques de cifrado
AES256-GCM	Estándar de cifrado avanzado de 256 bits en modo Galois/Counter Disponible solo en Linux. MongoDB Enterprise en Windows ya no admite AES256-GCM como un cifrado de bloques para el cifrado en reposo. Este uso solo es compatible con Linux.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--encryptionKeyFile <string>

La ruta al archivo de clave local cuando se gestionan las claves mediante un proceso distinto al KMIP. Solo se configura cuando se gestionan claves mediante un proceso distinto a KMIP. Si los datos ya están cifrados con KMIP, MongoDB genera un error.

El archivo de claves puede contener solo una clave. La clave es un string de 16 o 32 caracteres.

Requiere --enableEncryption.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipKeyIdentifier <string>

Identificador único de KMIP para una clave existente en el servidor KMIP. Incluido para utilizar la clave asociada con el identificador como clave del sistema. Solo puede usar la configuración la primera vez que active el cifrado para la instancia mongod. Requiere --enableEncryption.

Si no se especifica, MongoDB hace una solicitud de que el servidor KMIP cree una nueva clave para usar como clave del sistema.

Si el servidor KMIP no puede localizar una clave con el identificador especificado o los datos ya están cifrados con una clave, MongoDB genera un error

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipRotateMasterKey <boolean>

Por defecto: false

Si es verdadero, rote la clave maestra y vuelva a cifrar el almacén de claves interno.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

Tip

Rotación de la clave maestra de KMIP

--kmipServerName <string>

Nombre de host o dirección IP del servidor KMIP al que conectarse. Requiere --enableEncryption.

Puede especificar varios servidores KMIP como una lista separada por comas, por ejemplo: server1.example.com,server2.example.com. Al iniciarse, mongod intenta establecer una conexión con cada servidor en el orden enumerado y selecciona el primer servidor al que puede conectarse exitosamente. La selección del servidor KMIP ocurre solo al inicio.

Al conectarse a un servidor KMIP, mongod verifica que el --kmipServerName especificado coincida con el Nombre alternativo del sujeto SAN (o, si SAN no está presente, el Nombre común CN) en el certificado presentado por el servidor KMIP. Si SAN está presente, mongod no coincide con CN. Si el nombre de host no coincide con SAN (o CN), mongod no se puede conectar.

A partir de MongoDB 4.2, al realizar una comparación de SAN, MongoDB admite la comparación de nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo admitía comparaciones de nombres DNS.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipPort <number>

por defecto: 5696

Número de puerto que se debe usar para comunicarse con el servidor KMIP. Requiere --kmipServerName. Requiere --enableEncryption.

Si se especifican varios servidores KMIP con --kmipServerName, el mongod utiliza el puerto especificado con --kmipPort para todos los servidores KMIP proporcionados.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipConnectRetries <number>

Por defecto: 0

Cuántas veces se debe reintentar la conexión inicial al servidor KMIP. Utilizar junto con --kmipConnectTimeoutMS para controlar cuánto tiempo el mongod espera una respuesta entre cada reintento.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipConnectTimeoutMS <number>

Por defecto: 5000

Tiempo de espera en milisegundos para recibir una respuesta del servidor KMIP. Si se especifica la configuración --kmipConnectRetries, el mongod espera el intervalo especificado entre reintentos.

El valor debe ser 1000 o mayor.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipClientCertificateSelector <string>

Nuevo en la versión 5.0: Disponible en Windows y macOS como una alternativa a --kmipClientCertificateFile.

--kmipClientCertificateFile y --kmipClientCertificateSelector son opciones mutuamente excluyentes. Solo puedes especificar uno.

Especifica una propiedad del certificado para seleccionar un certificado coincidente de los almacenes de certificados del sistema operativo para autenticar MongoDB ante el servidor KMIP.

--kmipClientCertificateSelector acepta un argumento en el formato <property>=<value> donde la propiedad puede ser una de las siguientes:

Propiedad	Tipo de valor	Descripción
subject	string ASCII	Nombre del sujeto o nombre común en el certificado
thumbprint	cadena hexadecimal	Una secuencia de bytes, expresada en hexadecimal, utilizada para identificar una llave pública mediante su resumen SHA-1. El thumbprint a veces se conoce como fingerprint.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipClientCertificateFile <string>

Ruta al archivo .pem utilizado para autenticar MongoDB en el servidor KMIP. El archivo .pem especificado debe contener tanto el certificado TLS/SSL como la clave.

Para usar esta opción, también debe especificar la opción --kmipServerName.

Nota

En macOS o Windows, puedes usar un certificado del almacén seguro del sistema operativo en lugar de un archivo de llave PEM. Consulta --kmipClientCertificateSelector.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipClientCertificatePassword <string>

La contraseña para descifrar la llave privada del certificado del cliente que se conecta al servidor KMIP. Esta opción autentica MongoDB al servidor KMIP y requiere que proporciones un --kmipClientCertificateFile.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipServerCAFile <string>

Ruta al archivo de CA. Se utiliza para validar la conexión segura del cliente al servidor KMIP.

Nota

En macOS o Windows, puede usar un certificado del almacén seguro del sistema operativo en lugar de un archivo de llave PEM. Consulte --kmipClientCertificateSelector. Cuando utilice el almacén seguro, no necesita, pero puede, también especificar el --kmipServerCAFile.

--kmipActivateKeys <boolean>

Por defecto: true

Novedades en la versión 5.3.

Activa todas las claves KMIP recién creadas al momento de su creación y luego verifica periódicamente que dichas claves estén en estado activo.

Cuando --kmipActivateKeys es true y hay claves existentes en un servidor KMIP, la clave debe activarse primero o el nodo mongod no se iniciará.

Si la clave que está utilizando el mongod pasa a un estado no activo, el nodo mongod se apaga a menos que kmipActivateKeys sea falso. Para asegurarse de que tiene una clave activa, rote la clave maestra KMIP usando --kmipRotateMasterKey.

--kmipKeyStatePollingSeconds <integer>

Por defecto: 900 segundos

Novedades en la versión 5.3.

Frecuencia en segundos a la que mongod consulta el servidor KMIP para obtener claves activas.

Para desactivar la función de sondeo, establezca el valor en -1.

--kmipUseLegacyProtocol <boolean>

Por defecto: false

Nuevo en la versión 7.0: (y 6.0.6)

Cuando true, mongod utiliza la versión 1.0 o 1.1 del protocolo KMIP en lugar de la versión por defecto. El protocolo KMIP por defecto es la versión 1.2.

Para usar el cifrado de registros de auditoría con KMIP versión 1.0 o 1.1, debes especificar auditEncryptKeyWithKMIPGet al inicio.

--eseDatabaseKeyRollover

Pase el cursor sobre las claves de la base de datos del motor de almacenamiento cifrado configuradas con el cifrado AES256-GCM.

Cuando la instancia mongod se inicia con esta opción, la instancia rota las claves y se cierra.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.