mongod Instancias

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á habilitada, MongoDB requiere que todos los clientes se autentiquen antes de determinar su acceso.

Para configurar usuarios, utilice el cliente. Si no existen usuarios, la interfaz localhost tendrá acceso a la base de datos hasta que cree el primer mongosh 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 escucha las conexiones de los clientes. Puede conectar mongod a cualquier interfaz. Para vincularse a varias direcciones, introduzca 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 resuelve en una 6 --bind_ip mongod --ipv6 6 6 dirección IPv para, debe comenzar con para habilitar la --bind_ip compatibilidad con IPv. Especificar una dirección IPv para no habilita la6 compatibilidad con IPv.

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

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 mongod instancia se enlaza a todas las4 direcciones IPv (es0.0.0.0 decir,). Si mongod comienza --ipv6 con, también se enlaza a todas--bind_ip_all las6 direcciones IPv (es:: decir,).

mongod Solo admite IPv6 si comienza 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/rangos CIDR(Classless Inter-Domain Routing) contra los cuales el mongod valida las solicitudes de autenticación de otros miembros del conjunto de réplicas y, si forma parte de un clúster fragmentado, de mongos las mongod instancias. El 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 mongos el.

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

--clusterIpSourceAllowlist acepta múltiples direcciones IPv4/ separadas por6 comas o rangos de enrutamientoentre dominios sin clases (CIDR):

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

Importante

--clusterIpSourceAllowlist Asegúrese de que incluya la dirección IP o los rangos CIDR que incluyan la dirección IP de cada miembro del mongos conjunto de réplicas o en la implementación para garantizar una comunicación saludable 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 --configExpand para,mongod devuelve un error y finaliza.

Para obtener más información sobre las directivas de expansión, consulte Valores de configuración externos para MongoDB autogestionado para obtener 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

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

Por mongod defecto, no se ejecuta como un demonio. Para ejecutar mongod como un demonio,--fork utilice o un proceso de control que gestione la demonización, como upstart systemdo.

Para usar, configure la salida de registro --fork para mongod con una de las siguientes opciones:

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

La configuración no --ipv6 indica a que mongod escuche en ninguna6 dirección o interfaz IPv local. Para configurar para que mongod escuche en una interfaz IPv,6 debe:

• Configure con una o --bind_ip más6 direcciones IPv o nombres de host que se resuelvan en6 direcciones IPv, o

• Establecer --bind_ip_all a.true

--keyFile <file>

Especifica la ruta a un archivo de clave que almacena el secreto compartido que las instancias de MongoDB utilizan para autenticarse entre sí en un clúster fragmentado o un conjunto de réplicas. --keyFile --authimplica. Consulte Autenticación interna/de membresía autogestionada 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 por defecto del parámetro listenBacklog depende del sistema de destino. En Linux, MongoDB utiliza /proc/sys/net/core/somaxconn. En todos los demás sistemas de destino, MongoDB utiliza la constante de tiempo de compilación SOMAXCONN.

Algunos sistemas pueden interpretar SOMAXCONN de forma simbólica, y otros, numérica. El listen backlog real aplicado en la práctica puede diferir de cualquier interpretación numérica de la constante SOMAXCONN o del argumento a --listenBacklog.

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.

--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 archivo de registro existente en lugar de sobrescribirlo. Para agregar información al archivo de registro, configure la --logappend opción.

--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 reopen especifica, también debe --logappend usar.

--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 que los enumera también importa, al igual que el iniciador de la comunicación. Por ejemplo, si mongosh especifica los compresores de red zlib,snappy y mongod snappy,zlibespecifica, los mensajes entre mongosh y mongod zlibutilizan.

Si las partes no comparten al menos un compresor común, los mensajes entre las partes no se comprimen. 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

Deshabilita la escucha en el socket de dominio UNIX. se aplica solo a sistemas basados ​​en--nounixsocket 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 Debian y de Red Hat o CentOS tienen la configuración bind_ip establecida en 127.0.0.1 por defecto.

--outputConfig

Muestra las mongod opciones de configuración de la instancia, formateadas en YAML, en stdout y sale de la mongod instancia. Para las opciones de configuración que utilizan valores de configuración externos para MongoDB autogestionado, --outputConfig devuelve el valor resuelto para 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 la ubicación del archivo donde se almacenará el ID de proceso (PID) del mongod proceso. El usuario que ejecuta el proceso mongod o mongos debe tener permisos de escritura en esta ruta. Si --pidfilepath no se especifica la opción, el proceso no crea un archivo PID. Utilice esta opción principalmente junto con la --fork opción.

Nota

Linux

En Linux, la gestión /etc/init.d systemctl de archivos PID suele ser responsabilidad del sistema de inicio de tu distribución: normalmente un archivo de servicio en el directorio o un archivo de unidad systemd registrado con. Utiliza la --pidfilepath opción solo si no estás usando uno de estos sistemas de inicio. Para más información, consulta la guía de instalación correspondiente a tu sistema operativo.

Nota

macOS

En macOS, la gestión de archivos PID generalmente se realiza brew mediante. Utilice la --pidfilepath opción solo si no está utilizando brew en su sistema macOS. Para obtener más información, consulte la Guía de instalación correspondiente a su 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.

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

--quiet

Ejecuta mongod en un modo silencioso que limita la 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

• client metadata

--redactClientLogData

Disponible solamente en MongoDB Enterprise.

Un mongod que --redactClientLogData se ejecuta con oculta cualquier mensaje que acompañe a un evento de registro determinado antes de registrarlo. Esto evita que escriba mongod datos potencialmente confidenciales almacenados en la base de datos en el registro de diagnóstico. Los metadatos, como los códigos de error u operación, los números de línea y los nombres de los archivos de origen, siguen siendo visibles en los registros.

Utilice junto --redactClientLogData con el cifrado en reposo y TLS/SSL (cifrado de transporte) para facilitar el cumplimiento de los requisitos reglamentarios.

Por ejemplo, una implementación de MongoDB podría almacenar información de identificación personal (PII) en una o más colecciones. La mongod instancia registra eventos como operaciones CRUD y metadatos de fragmentación, y podría exponer PII como parte de estas operaciones de registro. Una mongod instancia --redactClientLogData que se ejecuta con elimina cualquier mensaje que acompañe a estos eventos antes de escribirlos en el registro, lo que elimina la PII.

El diagnóstico de un mongod proceso que --redactClientLogData se ejecuta con puede resultar más difícil 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 del registro.

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 finaliza de forma limpia y segura --shutdown el mongod proceso. Al invocar mongod con esta opción, debe configurar la opción directamente o --dbpath a través del archivo de configuración y la --config opción.

La opción solo está disponible en sistemas --shutdown 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 un archivo de registro (--logpath).

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

Advertencia

El syslog demonio genera marcas de tiempo al registrar un mensaje, no cuando MongoDB lo emite. Esto puede generar marcas de tiempo erróneas en los registros, especialmente cuando el sistema está bajo una carga elevada. Recomendamos usar la --logpath opción en sistemas de producción para 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 funcionalidad utilizado para 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 habilitar la --syslog opción.

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

El formato de marca de tiempo ya no es compatible con ctime. Un ejemplo de 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 librería de terceros timelib para proporcionar conversiones precisas entre zonas horarias. Debido a una actualización reciente, timelib podría crear conversiones de zonas horarias inexactas en versiones anteriores de MongoDB.

Para vincular explícitamente con la base de datos de zonas horarias en versiones de MongoDB anteriores 5.0 a, descargue la base de datos de zonas horarias y utilice el timeZoneInfo parámetro.

Tip

processManagement.timeZoneInfo.

--traceExceptions

Solo para uso diagnóstico interno.

--transitionToAuth

Permite que mongod acepte y cree conexiones autenticadas y no autenticadas hacia y desde otras mongod instancias y en el despliegue. Se utiliza para realizar una transición mongos gradual de conjuntos de réplicas o clústeres fragmentados desde una configuración sin autenticación a una autenticación interna. Requiere especificar un mecanismo de autenticación interno --keyFile como.

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 usuario. Los usuarios pueden conectarse a su implementación sin ninguna comprobación de control de acceso y realizar operaciones de lectura, escritura y administración.

Nota

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

--unixSocketPrefix <path>

Por defecto: /tmp

La ruta para el socket UNIX. se aplica solo a sistemas basados ​​en--unixSocketPrefix 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 en varios servidores LDAP, especifique un servidor LDAP o cualquiera de sus instancias replicadas en. MongoDB admite las --ldapServers siguientes referencias LDAP 4511 4 definidas en RFC,110 y. 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

Un indicador que determina si la mongod instancia comprueba la disponibilidad de como parte de su LDAP server(s) 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.

• Utilizando una consulta LDAP username transformation para.

• El servidor LDAP no permite conexiones anónimas

Debes usar --ldapQueryUser --ldapQueryPasswordcon.

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--ldapBindWithOSDefaultsen lugar de--ldapQueryUsery--ldapQueryPassword. No se pueden especificar--ldapQueryUsery--ldapBindWithOSDefaultsal mismo tiempo.

--ldapQueryPassword <string | array>

Disponible solamente en MongoDB Enterprise.

La contraseña utilizada para conectarse a un servidor LDAP cuando se utiliza. Debe --ldapQueryUser utilizar --ldapQueryPassword --ldapQueryUsercon.

Si nomongod se establece, no intenta conectarse al servidor LDAP.

Puede configurar este ajuste en un en ejecución mongod setParameterusando.

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.

• Utilizando una consulta LDAP username transformation para.

• El servidor LDAP no permite conexiones anónimas

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

--ldapBindMethod <string>

Por defecto: simple

Disponible solamente en MongoDB Enterprise.

El método se mongod utiliza para autenticarse en un servidor LDAP. Úselo con --ldapQueryUser y para conectarse al servidor --ldapQueryPassword LDAP.

--ldapBindMethod admite los siguientes valores:

• simple - mongod utiliza autenticación sencilla.

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

Si sasl especifica, puede configurar los mecanismos SASL disponibles --ldapBindSaslMechanisms usando. mongod usa por defecto el DIGEST-MD5 mecanismo.

--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 Windows Kerberos genera automáticamente un Ticket de Concesión de Tickets cuando el usuario inicia sesión en el sistema. Configure --ldapBindWithOSDefaults con true para permitir mongod que utilice las credenciales generadas al conectarse al servidor de Active Directory y ejecutar consultas.

Establezca --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, se puede consultar 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 deshabilitar TLS/SSL entre mongod y el servidor LDAP.

Advertencia

Configurar --ldapTransportSecurity a none 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.

Aumentar el valor de --ldapTimeoutMS puede evitar fallos de conexión entre el servidor MongoDB y el servidor LDAP, si la causa del fallo es un tiempo de espera agotado. Disminuir el valor de reduce el tiempo que MongoDB espera una respuesta del servidor --ldapTimeoutMS 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.

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

• 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 un que requiere un LDAP authorization query template DN.

• 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 una matriz ordenada de documentos. Cada documento contiene una expresión regular match y una substitution ldapQuery plantilla o 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	Plantilla de formato de nombre distinguido (DN) LDAP que convierte el nombre de autenticación que coincide con la match expresión regular en un DN LDAP. 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 regular. El resultado de la sustitución debe ser una 4514 cadena de escape RFC.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Una plantilla match 4515 4516de formato de consulta LDAP que inserta el nombre de autenticación que coincide con la match expresión regular en una URI de consulta LDAP codificada según RFC y RFC. 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. mongod ejecuta la consulta contra el servidor LDAP para recuperar el DN LDAP del 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

La explicación de 4514RFC, RFC,4515 RFC4516 o las consultas LDAP queda fuera del alcance de la documentación de MongoDB. Consulte directamente el RFC o utilice su 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 una "" cadena vacía o una matriz vacía [ ] en lugar de un documento de mapeo. Si se proporciona una cadena vacía o una matriz vacía --ldapUserToDNMapping a, MongoDB mapea el nombre de usuario autenticado como el DN de LDAP. En versiones anteriores, proporcionar un documento de mapeo vacío provoca que el mapeo falle.

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 array a como una --ldapUserToDNMapping cadena.

"[
   {
      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 no está --ldapUserToDNMapping definido, mongod no aplica ninguna transformación al nombre de usuario cuando intenta autenticar o autorizar a un usuario contra 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 consulta LDAP relativa formateada conforme a RFC4515 y RFC4516 que mongod ejecuta para obtener los grupos LDAP a los que pertenece el usuario autenticado. La consulta es relativa al host o hosts especificados --ldapServers en.

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 transformed nombre de usuario si se especifica username mapping un.
{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

La explicación de RFC,4515 RFC4516 o consultas LDAP queda fuera del alcance de la documentación de MongoDB. Consulte directamente el RFC o utilice su 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 un mongod con un que contiene archivos de datos producidos --dbpath --storageEngine por mongod un motor de almacenamiento distinto al especificado por, 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--dbpathdeben 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 independiente para almacenar los datos de cada base de datos. Los directorios se encuentran dentro del --dbpath directorio, y el nombre de cada subdirectorio corresponde al nombre de la base de datos.

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

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

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

• Para instancias autónomas:

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

  2. Detén la instancia mongod.

  3. Agregue el --directoryperdb valor y configure un nuevo directorio de datos.

  4. Reinicia la instancia mongod.

  5. Utilice para rellenar el nuevo directorio de mongorestore datos.

• Para set de réplicas:

  1. Detén un miembro secundario.

  2. Agregue el --directoryperdb valor y configure 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 mongod proceso escribe datos muy rápidamente en el diario y de forma diferida en los archivos de datos. --syncdelay no tiene efecto en el registro, pero si --syncdelay se establece en,0 el diario eventualmente consume todo el espacio disponible en el disco.

No disponible para instancias que utilizan mongod 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 a la última versión, si es --dbpath 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 únicamente si no dispone de otras opciones. Esta operación elimina los datos corruptos durante el proceso de reparación, pero no los mongod --repair guarda.

• Evite ejecutar contra un miembro del conjunto de --repair 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 elige ejecutar en un miembro del conjunto de réplicas y la operación modifica los datos o los metadatos, aún debe realizar una resincronización completa para que el miembro se vuelva a unir al conjunto de mongod --repair réplicas.

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

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

--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 que utilizan mongod 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.

Evite aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado. Si su caso de uso lo requiere, puede usar para especificar un porcentaje de --wiredTigerCacheSizePct hasta 80% de la memoria disponible. Los valores pueden oscilar 0 entre,256GB y 10000GB.

Para obtener más información, consulta Uso de memoria.

Nota

En algunas instancias, como cuando se ejecuta en un contenedor que está para usar menos RAM que la cantidad de memoria aprovisionada para el host, se deben tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger en un valor apropiado, ya que es posible que WiredTiger no tenga en cuenta los límites de memoria del contenedor específico en ciertos casos.

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

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

Se puede especificar un porcentaje de hasta un 80% de la memoria disponible. El rango de valores calculado es de 0.256GB a 10000GB. Por ejemplo, en un sistema con 2GB de RAM, el --wiredTigerCacheSizePct no se puede establecer en 10 porque el 10% de 2GB es 0.2GB, que es menos que 0.256GB.

Para obtener más información sobre los límites de memoria, consulta Uso de memoria.

Nota

En algunas instancias, como cuando se ejecuta en un contenedor que está para usar menos RAM que la cantidad de memoria aprovisionada para el host, se deben tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger en un valor apropiado, ya que es posible que WiredTiger no tenga en cuenta los límites de memoria del contenedor específico en ciertos casos.

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

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 límite restringe 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 memoria. Además, el sistema operativo utiliza la RAM libre para almacenar en búfer los bloques del sistema de archivos y la caché del sistema de --wiredTigerCacheSizePct 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 única instancia por máquina. Si mongod una sola máquina contiene varias instancias de MongoDB, reduzca la configuración para dar cabida a las otras instancias.mongod

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

Solo puede proporcionar uno de los --wiredTigerCacheSizePct siguientes --wiredTigerCacheSizeGB valores: o.

--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 se empieza mongod --wiredTigerDirectoryForIndexescon, mongod almacena los índices y las colecciones en subdirectorios separados dentro del directorio de datos (es--dbpath decir,). Específicamente, mongod almacena los índices en un subdirectorio llamado index y los datos de la colección en un subdirectorio collection llamado.

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 modifica el valor de --wiredTigerCollectionBlockCompressor en una implementación existente de MongoDB, todas las colecciones nuevas usarán el compresor especificado. Las colecciones existentes seguirán usando el compresor especificado al crearse o el compresor predeterminado en ese momento.

--wiredTigerIndexPrefixCompression <boolean>

Por defecto: true

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

Especifique true para para --wiredTigerIndexPrefixCompression habilitar la compresión de prefijos para los datos de índice, o false para deshabilitar la compresión de prefijos para los datos de índice.

La configuración afecta a todos los índices --wiredTigerIndexPrefixCompression --wiredTigerIndexPrefixCompression creados. Si modifica el valor de en una implementación existente de MongoDB, todos los índices nuevos usarán compresión de prefijo. Los índices existentes no se verán 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 mongod haya creado el oplog por primera vez, cambiar la --oplogSize opción no afectará el tamaño del oplog. Para cambiar el período mínimo de retención del oplog después mongod de iniciar,replSetResizeOplog use. replSetResizeOplog le permite redimensionar el oplog dinámicamente sin reiniciar el mongod proceso. Para que los cambios realizados con persistan después de un reinicio, actualice el replSetResizeOplog valor --oplogSize de.

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 del oplog después de iniciar,mongod replSetResizeOploguse. replSetResizeOplog permite redimensionar el oplog dinámicamente sin reiniciar el mongod proceso. Para que los cambios realizados con persistan replSetResizeOplog tras un reinicio, actualice el valor --oplogMinRetentionHours de.

--enableMajorityReadConcern

Por defecto: true

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

A partir de MongoDB,5.0 no se puede cambiar y siempre se establece--enableMajorityReadConcern true en. En versiones anteriores de MongoDB, era--enableMajorityReadConcern 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 (write concern) "majority" puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulte Mitigar problemas de rendimiento en sets de réplicas autogestionados.

• 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 mongod instancia sirve como servidor de configuración de un clúster fragmentado. Al ejecutarse con esta opción, los clientes (es decir, otros componentes del clúster) no pueden escribir datos en ninguna base de datos que no sea config admino. El puerto predeterminado para una mongod instancia con esta opción es 27019 y el --dbpath directorio predeterminado /data/configdb es, a menos que se especifique lo contrario.

Importante

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

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 crea --configsvr un oplog local.

No utilice la --configsvr opción con. Los servidores de configuración no pueden ser servidores de --shardsvr fragmentación.

No utilice el --configsvr parámetro con el skipShardingConfigurationChecks parámetro. Es decir, si inicia temporalmente el mongod de forma independiente para operaciones de mantenimiento, incluya el parámetro skipShardingConfigurationChecks y excluya --configsvr el. Una vez finalizado el mantenimiento, elimine el skipShardingConfigurationChecks parámetro y reinicie con --configsvr el.

--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 --shardsvr con, también debe especificar --replSet un.

No utilice el --shardsvr parámetro con el skipShardingConfigurationChecks parámetro. Es decir, si inicia temporalmente el mongod de forma independiente para operaciones de mantenimiento, incluya el parámetro skipShardingConfigurationChecks y excluya --shardsvr el. Una vez finalizado el mantenimiento, elimine el skipShardingConfigurationChecks parámetro y reinicie con --shardsvr el.

--replicaSetConfigShardMaintenanceMode

Configura la instancia de mongod para que se inicie en modo de mantenimiento. La opción desactiva algunas comprobaciones de inicio, lo que te permite convertir un set de réplicas en un clúster segmentado con un shard de configuración incrustado.

Nuevo en la versión 8.3.

Opciones de TLS

--tlsMode <mode>

Habilita el uso de TLS para todas las conexiones de red. El argumento para la opción puede ser uno de los --tlsMode 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 la509 autenticación X., --tlsCAFile se tls.CAFile debe especificar o a menos que --tlsCertificateSelector se utilice.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración TLS/SSL para clientes .

--tlsCertificateKeyFile <filename>

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

En macOS o Windows, puede usar la opción para especificar un certificado del almacén de certificados seguros --tlsCertificateSelector --tlsCertificateKeyFile del --tlsCertificateSelector sistema operativo en lugar de un archivo de clave PEM. Las opciones y son mutuamente excluyentes. Solo puede especificar una.

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

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

  Importante

  MongoDB, exclusivamente para Windows, no admite archivos PEM cifrados. El servidor no mongod 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,--tlsCertificateSelector utilice.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración TLS/SSL para clientes .

--tlsCertificateKeyFilePassword <value>

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

• En Linux/BSD, si la clave privada del archivo PEM está cifrada y no se especifica la --tlsCertificateKeyFilePassword opción, MongoDB solicita una contraseña. Consulte Contraseña del certificado TLS/SSL.

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

• En Windows, MongoDB no admite certificados cifrados. El método mongod falla si encuentra un archivo PEM cifrado. En su --tlsCertificateSelector lugar, utilice.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 la509 autenticación X., --tlsCAFile se tls.CAFile debe especificar o a menos que --tlsCertificateSelector se utilice.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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, puede usar la opción para especificar un certificado del almacén de certificados seguros --tlsClusterCertificateSelector --tlsClusterFile del --tlsClusterCertificateSelector sistema operativo en lugar de un archivo de clave PEM. Las opciones y son mutuamente excluyentes. Solo puede especificar una.

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

Si se utiliza la509 autenticación X., --tlsCAFile se tls.CAFile debe especificar o a menos que --tlsCertificateSelector se utilice.

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

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración TLS/SSL para clientes .

Importante

Solo para Windows, 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 la autenticación de miembros en Windows,--tlsClusterCertificateSelector utilice.

--tlsCertificateSelector <parameter>=<value>

Nota

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

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

Las --tlsCertificateKeyFile opciones y son mutuamente excluyentes. Solo puede especificar una.--tlsCertificateSelector

--tlsCertificateSelector acepta un argumento del 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 de certificados seguros del sistema operativo los certificados de CA necesarios para validar la cadena completa de certificados del certificado TLS especificado. Específicamente, el almacén de certificados seguros debe contener la CA raíz y cualquier certificado de CA intermedio necesario para construir la cadena completa de certificados del certificado TLS.No --tlsCAFile utilice ni para especificar el certificado de CA raíz --tlsClusterCAFile 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 utilizar el comandorotateCertificatesni el método de shelldb.rotateCertificates()cuando se utilizanet.tls.certificateSelectoro--tlsCertificateSelectorconfigurado en thumbprint.

--tlsClusterCertificateSelector <parameter>=<value>

Nota

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

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 Las --tlsClusterCertificateSelector opciones y son mutuamente excluyentes. Solo puede especificar una.

--tlsClusterCertificateSelector acepta un argumento del 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.

El mongod busca en el almacén de certificados seguros del sistema operativo los certificados de CA necesarios para validar la cadena completa del certificado de clúster especificado. En concreto, el almacén de certificados seguros debe contener la CA raíz y los certificados de CA intermedios necesarios para construir la cadena completa del certificado de clúster. No utilice --tlsCAFile ni --tlsClusterCAFile para especificar los certificados de CA raíz e intermedios.

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 / registra una advertencia en la conexión si mongos el509 certificado X. presentado caduca dentro 30 de los días de la mongod/mongos hora del sistema host.

--tlsClusterPassword <value>

Especifica la contraseña para descifrar el509 archivo de clave de certificado X.--tlsClusterFile especificado con. Utilice la opción solo si el archivo de clave de certificado está cifrado. En todos los casos, la --tlsClusterPassword opción mongod oculta la contraseña en todos los registros y la información de salida.

• En Linux/BSD, si la clave privada del509 archivo X. está cifrada y no se especifica la opción, MongoDB solicita una --tlsClusterPassword contraseña.Consulte Contraseña del certificado TLS/SSL.

• En macOS, si la clave privada del509 archivo X. está cifrada, debe especificar explícitamente la opción. Como alternativa, puede usar un --tlsClusterPassword --tlsClusterCertificateSelector certificado del almacén seguro del sistema (consulte) en lugar de un archivo PEM de clúster o usar un archivo PEM sin cifrar.

• En Windows, MongoDB no admite certificados cifrados. El método mongod falla si encuentra un archivo PEM cifrado. En su --tlsClusterCertificateSelector lugar, utilice.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 net.tls.CAFile la opción de configuración o tlsUseSystemCA el parámetro.

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

Solo para Windows/macOS

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

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración TLS/SSL para clientes .

--tlsClusterCAFile <filename>

Especifica el .pem archivo 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 .pem archivo utilizando rutas relativas o absolutas. requiere--tlsClusterCAFile que --tlsCAFile esté configurado.

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

--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 utiliza --tlsCertificateSelector --tlsClusterCertificateSelectory/o, no utilice para especificar los certificados CA raíz e intermedios. Almacene todos los certificados --tlsClusterCAFile --tlsCertificateSelector CA necesarios para --tlsClusterCertificateSelector validar la cadena de confianza completa de los certificados y/o en el almacén de certificados seguro.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 se puede especificar un archivo CRL en macOS. En su lugar, puede usar el almacén de certificados SSL del sistema, que utiliza OCSP (Protocolo de estado de certificado en línea) para validar el estado de revocación de los certificados. Consulte para obtener --tlsCertificateSelector más información sobre cómo usar 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 más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 usar la configuración, MongoDB registra una advertencia sobre el uso del certificado no --tlsAllowInvalidCertificates válido.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 los clientes que no proporcionan certificados, mongod o cifra la conexión TLS/SSL, suponiendo que la conexión se haya realizado mongos correctamente.

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

Utilice la opción si tiene una implementación mixta que incluye clientes que no presentan o no pueden presentar --tlsAllowConnectionsWithoutCertificates certificados mongod al.

Para más información acerca de TLS y MongoDB, consulta Configurar instancias de MongoDB para cifrado TLS/SSL y Configuración 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 siguientesTLS1_0 TLS1_1protocolos:,, TLS1_2 TLS1_3y.

• 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.1o superior está disponible en el sistema. Para habilitar TLS,1.0 especifique none entre --tlsDisabledProtocols y.

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 a mongod que utilice el modo FIPS de la biblioteca TLS. Su sistema debe tener una biblioteca compatible con FIPS para utilizar la --tlsFIPSMode opción.

A partir de MongoDB,8.3 no se puede especificar SCRAM-SHA-1 para mientras también authenticationMechanisms se especifica mongod --tlsFIPSMode mongos --tlsFIPSModeo.

Si intentas especificar SCRAM-SHA-1 para authenticationMechanisms mientras también especificas --tlsFIPSMode, el servidor arroja un error y registra un mensaje similar al siguiente:

SCRAM-SHA-1 is not allowed in FIPS mode.

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 perfilador recopila datos para operaciones que exceden el umbral slowms o coinciden con un filtro especificado.

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 lento, en milisegundos. Las operaciones que se ejecutan por más tiempo que este umbral se consideran lentas.

Las operaciones lentas se registran en función de workingMillis, que es la cantidad de tiempo que MongoDB dedica a trabajar en esa operación. Esto significa que factores como la espera de bloqueos y el control de flujo no afectan si una operación supera el umbral de operación lenta.

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 mongod instancias, afecta al registro de diagnóstico y, si está habilitado, al generador de--slowms perfiles.

Tip

Database Profiler

--defaultSlowInProgMS <integer>

Por defecto: 5000

El umbral de operation time lenta para una consulta en curso, en milisegundos. MongoDB registra como consultas lentas en curso aquellas operaciones que se ejecutan durante más tiempo que este umbral. MongoDB registra una query como una query en curso lenta tan pronto como la operación de query supera el umbral de tiempo.

--slowOpSampleRate <double>

Por defecto: 1.0

La fracción de operaciones lentas que deben ser analizadas o registradas. acepta valores --slowOpSampleRate entre 0 y,1 ambos inclusive.

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

Para mongod instancias, afecta al registro de diagnóstico y, si está habilitado, al generador de--slowOpSampleRate perfiles.

Opciones de auditoría

--auditCompressionMode

Nuevo en la versión 5.3.

Especifica el modo de compresión para el cifrado del registro de auditoría. También debe habilitar el cifrado del registro de auditoría mediante --auditEncryptionKeyUID --auditLocalKeyFileo.

Puedes establecer esta opción 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	Generar los eventos de auditoría en el archivo especificado en --auditPath en el formato especificado --auditFormat en.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditEncryptionKeyUID

Nuevo 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 puedes usar esta opción y --auditLocalKeyFile juntas.

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 la auditoría --auditDestination si file es. La opción puede tener uno de los siguientes --auditFormat valores:

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

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

Nuevo 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 esta opción únicamente para realizar pruebas, ya que la clave no está protegida. Para proteger la clave, utilice --auditEncryptionKeyUID y un servidor externo del Protocolo de Interoperabilidad de Gestión de Claves (KMIP).

No puede utilizar ambas opciones a la vez.

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 el valor file de. La opción puede tomar una ruta completa o una ruta --auditPath 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.

--auditSchema

Por defecto: mongo

Nuevo en la versión 8.0.

Especifica el formato utilizado para los registros de auditoría. Puede especificar uno de los siguientes valores para --auditSchema:

Valor	Descripción
mongo	Los registros se escriben en un formato diseñado por MongoDB. Para ver ejemplos de mensajes de registro, consulta mensajes de auditoría del esquema mongo.
OCSF	Los registros se escriben en formato OCSF. Esta opción proporciona registros en un formato estandarizado compatible con los procesadores de logs. Para ejemplos de mensajes de registro, consulta Esquema de Mensajes de Auditoria OCSF.

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 KMIP único para una clave existente en el servidor KMIP. Incluya esta opción para usar la clave asociada al identificador como clave del sistema. Solo puede usar esta configuración la primera vez que habilite el cifrado para la mongod instancia.--enableEncryption Requiere.

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

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, el mongod verifica que el especificado coincida con el Nombre Alternativo del --kmipServerName Sujeto SAN (o, si SAN no está presente, con el Nombre CN Común) en el certificado presentado por el servidor KMIP. Si SAN está presente, mongod no coincide con CN el. Si el nombre de host no coincide con el SAN CN(o), la mongod conexión con el falla.

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 utilizará para comunicarse con el servidor KMIP.--kmipServerName Requiere.--enableEncryption Requiere.

Si se especifican varios servidores KMIP con,--kmipServerName el mongod utiliza el puerto especificado con para todos los servidores KMIP --kmipPort 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 con el servidor KMIP. Úselo junto con para controlar cuánto --kmipConnectTimeoutMS tiempo 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 obtener una respuesta del servidor KMIP. Si --kmipConnectRetries se especifica la configuración,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>

Novedades en la versión 5.0:

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

--kmipClientCertificateFile Las --kmipClientCertificateSelector opciones y son mutuamente excluyentes. Solo puede especificar una.

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 del 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 utilizar esta opción, también debe especificar la --kmipServerName opción.

Importante

La activación del cifrado mediante un servidor KMIP en Windows falla cuando se utiliza --kmipClientCertificateFile y el servidor KMIP aplica TLS 1.2.

Para activar el cifrado en reposo con KMIP en Windows, debes:

• Importa el certificado de cliente en el Almacén de certificados de Windows.

• Utilice la --kmipClientCertificateSelector opción de configuración.

Nota

En macOS o Windows, puede usar un certificado del almacén seguro del sistema operativo en lugar de un archivo de clave PEM.--kmipClientCertificateSelector Consulte.

Nota

Característica de la empresa

Disponible solamente en MongoDB Enterprise.

--kmipClientCertificatePassword <string>

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

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 clave PEM. Consulte. Al usar el almacén seguro, no es necesario, pero puede --kmipClientCertificateSelector especificar --kmipServerCAFile también.

--kmipActivateKeys <boolean>

Por defecto: true

Nuevo 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 tiene claves existentes en un servidor KMIP, la clave debe activarse primero o el nodo no se mongod iniciará.

Si la clave que utiliza mongod pasa a un estado inactivo, el mongod nodo se apaga a menos que kmipActivateKeys sea falso. Para garantizar que tenga una clave activa, rote la clave maestra de KMIP --kmipRotateMasterKey usando.

--kmipKeyStatePollingSeconds <integer>

Por defecto: 900 segundos

Nuevo 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

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

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.