mongodOn this page本页内容
mongod is the primary daemon process for the MongoDB system. 是MongoDB系统的主要守护进程。It handles data requests, manages data access, and performs background management operations.它处理数据请求，管理数据访问，并执行后台管理操作。
This document provides a complete overview of all command line options for 本文档提供了mongod. mongod所有命令行选项的完整概述。These command line options are primarily useful for testing: In common operation, use the configuration file options to control the behavior of your database.这些命令行选项主要用于测试：在常见操作中，使用配置文件选项控制数据库的行为。
Starting in version 4.0, MongoDB disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available. 从4.0版开始，MongoDB在TLS 1.1+可用的系统上禁用对TLS 1.0加密的支持。For more details, see Disable TLS 1.0.有关详细信息，请参阅禁用TLS 1.0。
Changed in version 5.2.在版本5.2中更改。
--cpu command-line option.--cpu命令行选项。Changed in version 5.0.在版本5.0中更改。
--serviceExecutor command-line option and the corresponding net.serviceExecutor configuration option.--serviceExecutor命令行选项和相应的net.serviceExecutor配置选项。Changed in version 4.4.在版本4.4中更改。
--noIndexBuildRetry command-line option and the corresponding storage.indexBuildRetry option.--noIndexBuildRetry命令行选项和相应的storage.indexBuildRetry选项。Changed in version 4.2.在版本4.2中更改。
--tlsClusterCAFile/net.tls.clusterCAFile. --tlsClusterCAFile/net.tls.clusterCAFile。--help, -h
Returns information on the options and use of 返回有关mongod.mongod选项和使用的信息。
--version
Returns the 返回mongod release number.mongod版本号。
--config <filename>, -f <filename>
Specifies a configuration file for runtime configuration options. 指定运行时配置选项的配置文件。The configuration file is the preferred method for runtime configuration of 配置文件是mongod. mongod运行时配置的首选方法。The options are equivalent to the command-line configuration options. 这些选项与命令行配置选项等效。See Configuration File Options for more information.有关详细信息，请参阅配置文件选项。
Ensure the configuration file uses ASCII encoding. 确保配置文件使用ASCII编码。The mongod instance does not support configuration files with non-ASCII encoding, including UTF-8.mongod实例不支持非ASCII编码的配置文件，包括UTF-8。
--configExpand <none|rest|exec>
Default: none
New in version 4.2.在版本4.2中新增。
Enables using Expansion Directives in configuration files. 启用在配置文件中使用扩展指令。Expansion directives allow you to set externally sourced values for configuration file options.扩展指令允许您为配置文件选项设置外部来源的值。
--configExpand supports the following expansion directives:支持以下扩展指令：
none | mongod does not expand expansion directives. mongod不扩展扩展指令。mongod fails to start if any configuration file settings use expansion directives.mongod将无法启动。
|
rest | mongod expands __rest expansion directives when parsing the configuration file.mongod在解析配置文件时扩展__rest扩展指令。
|
exec | mongod expands __exec expansion directives when parsing the configuration file.mongod在解析配置文件时扩展__exec扩展指令。
|
You can specify multiple expansion directives as a comma-separated list, e.g. 您可以将多个扩展指令指定为逗号分隔的列表，例如rest, exec. rest, exec。If the configuration file contains expansion directives not specified to 如果配置文件包含未指定给--configExpand, the mongod returns an error and terminates.--configExpand的扩展指令，mongod将返回错误并终止。
See Externally Sourced Configuration File Values for configuration files for more information on expansion directives.有关扩展指令的详细信息，请参阅配置文件的外部源配置文件值。
--verbose, -v
Increases the amount of internal reporting returned on standard output or in log files. 增加标准输出或日志文件中返回的内部报告量。Increase the verbosity with the 通过多次包含选项（例如-v form by including the option multiple times, (e.g. -vvvvv.)-vvvvv），增加-v表单的详细程度
Starting in version 4.2, MongoDB includes the Debug verbosity level (1-5) in the log messages. 从4.2版开始，MongoDB在日志消息中包含Debug详细级别（1-5）。For example, if the verbosity level is 2, MongoDB logs 例如，如果详细级别为2，MongoDB将记录D2. D2。In previous versions, MongoDB log messages only specified 在以前的版本中，MongoDB日志消息只指定了D for Debug level.D作为调试级别。
--quiet
Runs 在安静模式下运行mongod in a quiet mode that attempts to limit the amount of output.mongod，试图限制输出量。
This option suppresses:此选项抑制：
--port <port>
Default:默认值：
mongod is not a shard member or a config server membermongod不是分片成员或配置服务器成员mongod is a shard membermongod是分片成员mongod is a config server membermongod是config服务器成员The TCP port on which the MongoDB instance listens for client connections.MongoDB实例侦听客户端连接的TCP端口。
--bind_ip <hostnames|ipaddresses|Unix domain socket paths>
Default: 默认值：localhost
Starting in MongoDB 3.6, 从MongoDB 3.6开始，mongod bind to localhost by default. mongod默认绑定到localhost。See Default Bind to Localhost.请参见默认绑定到Localhost。
The hostnames and/or IP addresses and/or full Unix domain socket paths on which mongod should listen for client connections. mongod应侦听客户端连接的主机名和/或IP地址和/或完整Unix域套接字路径。You may attach 您可以将mongod to any interface. To bind to multiple addresses, enter a list of comma-separated values.mongod连接到任何接口。要绑定到多个地址，请输入逗号分隔的值列表。
You can specify both IPv4 and IPv6 addresses, or hostnames that resolve to an IPv4 or IPv6 address.您可以指定IPv4和IPv6地址，也可以指定解析为IPv4或IPv6地址的主机名。
If specifying an IPv6 address or a hostname that resolves to an IPv6 address to 如果将IPv6地址或解析为IPv6地址的主机名指定为--bind_ip, you must start mongod with --ipv6 to enable IPv6 support. --bind_ip，则必须使用--ipv6启动mongod以启用IPv6支持。Specifying an IPv6 address to 将IPv6地址指定为--bind_ip does not enable IPv6 support.--bind_ip不会启用IPv6支持。
If specifying a link-local IPv6 address(如果指定链接本地IPv6地址（fe80:：/10），则必须将区域索引附加到该地址（即fe80::：fe80::/10), you must append the zone index to that address (i.e. fe80::<address>%<adapter-name>).<address>%<adapter name>）。
To avoid configuration updates due to IP address changes, use DNS hostnames instead of IP addresses. 为了避免由于IP地址更改而导致的配置更新，请使用DNS主机名而不是IP地址。It is particularly important to use a DNS hostname instead of an IP address when configuring replica set members or sharded cluster members.在配置副本集成员或分片集群成员时，使用DNS主机名而不是IP地址尤为重要。
Use hostnames instead of IP addresses to configure clusters across a split network horizon. 使用主机名而不是IP地址来跨拆分网络范围配置群集。Starting in MongDB 5.0, nodes that are only configured with an IP address will fail startup validation and will not start.从MongDB 5.0开始，仅使用IP地址配置的节点将无法通过启动验证，无法启动。
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. 在绑定到非本地主机（例如，可公开访问的）IP地址之前，请确保已保护集群免受未经授权的访问。For a complete list of security recommendations, see Security Checklist. 有关安全建议的完整列表，请参阅安全检查表。At minimum, consider enabling authentication and hardening network infrastructure.至少，考虑启用身份验证并加强网络基础设施。
For more information about IP Binding, refer to the IP Binding documentation.有关IP绑定的更多信息，请参阅IP绑定文档。
To bind to all IPv4 addresses, enter 要绑定到所有IPv4地址，请输入0.0.0.0.0.0.0.0。
To bind to all IPv4 and IPv6 addresses, enter 要绑定到所有IPv4和IPv6地址，请输入::,0.0.0.0 or starting in MongoDB 4.2, an asterisk "*" (enclose the asterisk in quotes to avoid filename pattern expansion). ::,0.0.0.0或以MongoDB 4.2开头的星号"*"（将星号括在引号中以避免文件名模式扩展）。Alternatively, use the 或者，使用net.bindIpAll setting.net.bindIpAll设置。
--bind_ip and --bind_ip_all are mutually exclusive. --bind_ip和--bind_ip_all互斥。mongod to throw an error and terminate.mongod抛出错误并终止。--bind overrides the configuration file setting net.bindIp.--bind覆盖配置文件设置net.bindIp。--bind_ip_all
If specified, the 如果指定，mongod instance binds to all IPv4 addresses (i.e. 0.0.0.0). mongod实例将绑定到所有IPv4地址（即0.0.0.0）。If 如果mongod starts with --ipv6, --bind_ip_all also binds to all IPv6 addresses (i.e. ::).mongod以--ipv6开头，--bind_ip_all也会绑定到所有ipv6地址（即::）。
mongod only supports IPv6 if started with --ipv6. mongod仅支持以--ipv6开头的IPv6。Specifying 单独指定--bind_ip_all alone does not enable IPv6 support.--bind_ip_all不会启用IPv6支持。
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. 在绑定到非本地主机（例如，可公开访问的）IP地址之前，请确保已保护集群免受未经授权的访问。For a complete list of security recommendations, see Security Checklist. 有关安全建议的完整列表，请参阅安全检查表。At minimum, consider enabling authentication and hardening network infrastructure.至少，考虑启用身份验证并加强网络基础设施。
For more information about IP Binding, refer to the IP Binding documentation.有关IP绑定的更多信息，请参阅IP绑定文档。
Alternatively, you can set the 或者，您可以将--bind_ip option to ::,0.0.0.0 or, starting in MongoDB 4.2, to an asterisk "*" (enclose the asterisk in quotes to avoid filename pattern expansion).--bind_ip选项设置为::,0.0.0.0，或者从MongoDB 4.2开始设置为星号"*"（将星号括在引号中以避免文件名模式扩展）。
--bind_ip and --bind_ip_all are mutually exclusive. --bind_ip和--bind_ip_all互斥。That is, you can specify one or the other, but not both.也就是说，您可以指定其中之一，但不能同时指定两者。
--clusterIpSourceAllowlist <string>
New in version 5.0.在版本5.0中新增。
A list of IP addresses/CIDR (Classless Inter-Domain Routing) ranges against which the mongod validates authentication requests from other members of the replica set and, if part of a sharded cluster, the mongos instances. The mongod verifies that the originating IP is either explicitly in the list or belongs to a CIDR range in the list. If the IP address is not present, the server does not authenticate the mongod or mongos.
--clusterIpSourceAllowlist has no effect on a mongod started without authentication.
--clusterIpSourceAllowlist accepts multiple comma-separated IPv4/6 addresses or Classless Inter-Domain Routing (CIDR) ranges:
mongod --clusterIpSourceAllowlist 192.0.2.0/24,127.0.0.1,::1
Ensure --clusterIpSourceAllowlist includes the IP address or CIDR ranges that include the IP address of each replica set member or mongos in the deployment to ensure healthy communication between cluster components.
--clusterIpSourceWhitelist <string>
Deprecated in version 5.0:Use --clusterIpSourceAllowlist instead.
A list of IP addresses/CIDR (Classless Inter-Domain Routing) ranges against which the IP地址/CIDR（无类别域间路由）范围列表，mongod validates authentication requests from other members of the replica set and, if part of a sharded cluster, the mongos instances. mongod根据该列表验证来自副本集其他成员的身份验证请求，如果是分片集群的一部分，则验证mongos实例。The mongod verifies that the originating IP is either explicitly in the list or belongs to a CIDR range in the list. mongod验证源IP是否明确在列表中或属于列表中的CIDR范围。If the IP address is not present, the server does not authenticate the 如果IP地址不存在，则服务器不会对mongod or mongos.mongod或mongos进行身份验证。
--clusterIpSourceWhitelist has no effect on a 对未经身份验证启动的mongod started without authentication.mongod无效。
--clusterIpSourceWhitelist accepts multiple comma-separated IPv4/6 addresses or Classless Inter-Domain Routing (CIDR) ranges:接受多个逗号分隔的IPv4/6地址或无类别域间路由（CIDR）范围：
mongod --clusterIpSourceWhitelist 192.0.2.0/24,127.0.0.1,::1
Ensure 确保--clusterIpSourceWhitelist includes the IP address or CIDR ranges that include the IP address of each replica set member or mongos in the deployment to ensure healthy communication between cluster components.--clusterIpSourceWhitelist包含IP地址或CIDR范围，其中包含部署中每个副本集成员或mongo的IP地址，以确保集群组件之间的正常通信。
--ipv6
Enables IPv6 support. 启用IPv6支持。mongod disables IPv6 support by default.mongod默认禁用IPv6支持。
Setting 设置--ipv6不指示--ipv6 does not direct the mongod to listen on any local IPv6 addresses or interfaces. mongod侦听任何本地ipv6地址或接口。To configure the 要将mongod to listen on an IPv6 interface, you must either:mongod配置为在IPv6接口上侦听，您必须：
--bind_ip with one or more IPv6 addresses or hostnames that resolve to IPv6 addresses, or--bind_ip，或--bind_ip_all to true.--bind_ip_all设置为true。--listenBacklog <number>
Default: Target system ：目标系统SOMAXCONN constantSOMAXCONN常量
The maximum number of connections that can exist in the listen queue.侦听队列中可以存在的最大连接数。
Consult your local system's documentation to understand the limitations and configuration requirements before using this parameter.在使用此参数之前，请查阅本地系统的文档以了解限制和配置要求。
To prevent undefined behavior, specify a value for this parameter between 要防止未定义的行为，请为此参数指定一个介于1 and the local system SOMAXCONN constant.1和本地系统SOMAXCONN常量之间的值。
The default value for the listenBacklog parameter is set at compile time to the target system SOMAXCONN constant. listenBacklog参数的默认值在编译时设置为目标系统SOMAXCONN常量。SOMAXCONN is the maximum valid value that is documented for the backlog parameter to the listen system call.是为侦听系统调用的backlog参数记录的最大有效值。
Some systems may interpret 一些系统可以象征性地解释SOMAXCONN symbolically, and others numerically. SOMAXCONN，而另一些系统可以数字地解释SOMAX CONN。The actual listen backlog applied in practice may differ from any numeric interpretation of the 实际应用的实际侦听backlog可能与SOMAXCONN constant or argument to --listenBacklog, and may also be constrained by system settings like net.core.somaxconn on Linux.SOMAXCONN常量或参数--listenBacklog的任何数字解释不同，也可能受到系统设置（如Linux上的net.core.somaxconn）的限制。
Passing a value for the 传递listenBacklog parameter that exceeds the SOMAXCONN constant for the local system is, by the letter of the standards, undefined behavior. listenBacklog参数的值超过了本地系统的SOMAXCONN常量，按照标准的字母，这是未定义的行为。Higher values may be silently integer truncated, may be ignored, may cause unexpected resource consumption, or have other adverse consequences.较高的值可能会被静默整数截断，可能会被忽略，可能会导致意外的资源消耗，或具有其他不利后果。
On systems with workloads that exhibit connection spikes, for which it is empirically known that the local system can honor higher values for the backlog parameter than the 在具有呈现连接峰值的工作负载的系统上，根据经验可知，本地系统可以接受比SOMAXCONN constant, setting the listenBacklog parameter to a higher value may reduce operation latency as observed by the client by reducing the number of connections which are forced into a backoff state.SOMAXCONN常数更高的backlog参数值，将listenBacklog参数设置为更高的值可以通过减少强制进入回退状态的连接数量来减少客户端观察到的操作延迟。
--maxConns <number>
The maximum number of simultaneous connections that mongod will accept. mongod将接受的最大同时连接数。This setting has no effect if it is higher than your operating system's configured maximum connection tracking threshold.如果此设置高于操作系统配置的最大连接跟踪阈值，则此设置无效。
Do not assign too low of a value to this option, or you will encounter errors during normal application operation.不要为该选项指定太低的值，否则在正常应用程序操作期间会遇到错误。
--logpath <path>
Sends all diagnostic logging information to a log file instead of to standard output or to the host's syslog system. 将所有诊断日志信息发送到日志文件，而不是发送到标准输出或主机的syslog系统。MongoDB creates the log file at the path you specify.MongoDB在您指定的路径创建日志文件。
By default, MongoDB will move any existing log file rather than overwrite it. 默认情况下，MongoDB将移动任何现有日志文件，而不是覆盖它。To instead append to the log file, set the 要改为追加到日志文件，请设置--logappend option.--logappend选项。
--syslog
Sends all logging output to the host's syslog system rather than to standard output or to a log file (将所有日志输出发送到主机的syslog系统，而不是发送到标准输出或日志文件（--logpath).--logpath）。
The Windows不支持--syslog option is not supported on Windows.--syslog选项。
The syslog daemon generates timestamps when it logs a message, not when MongoDB issues the message. syslog守护进程在记录消息时生成时间戳，而不是在MongoDB发出消息时生成。This can lead to misleading timestamps for log entries, especially when the system is under heavy load. 这可能会导致日志条目的时间戳错误，特别是在系统负载较重时。We recommend using the 我们建议对生产系统使用--logpath option for production systems to ensure accurate timestamps.--logpath选项，以确保准确的时间戳。
Starting in version 4.2, MongoDB includes the component in its log messages to 从4.2版开始，MongoDB在其发送给syslog.syslog的日志消息中包含该组件。
... ACCESS [repl writer worker 5] Unsupported modification to roles collection ...
--syslogFacility <string>
Default: user
Specifies the facility level used when logging messages to syslog. 指定将消息记录到syslog时使用的设施级别。The value you specify must be supported by your operating system's implementation of syslog. 操作系统的syslog实现必须支持您指定的值。To use this option, you must enable the 要使用此选项，必须启用--syslog option.--syslog选项。
--logappend
Appends new entries to the end of the existing log file when the 当mongod instance restarts. mongod实例重新启动时，将新条目追加到现有日志文件的末尾。Without this option, 如果没有此选项，mongod will back up the existing log and create a new file.mongod将备份现有日志并创建新文件。
--logRotate <string>
Default: rename
Determines the behavior for the 确定在旋转服务器日志和/或审核日志时logRotate command when rotating the server log and/or the audit log. logRotate命令的行为。Specify either 指定rename or reopen:rename或reopen：
renamereopen closes and reopens the log file following the typical Linux/Unix log rotate behavior. 按照典型的Linux/Unix日志轮换行为关闭并重新打开日志文件。Use 使用Linux/Unix logrotate实用程序时，请使用reopen when using the Linux/Unix logrotate utility to avoid log loss.reopen以避免日志丢失。
If you specify 如果指定reopen, you must also use --logappend.reopen，则还必须使用--logappend。
--timeStampFormat <string>
Default: iso8601-local
The time format for timestamps in log messages. Specify one of the following values:日志消息中时间戳的时间格式。指定以下值之一：
iso8601-utc | 1970-01-01T00:00:00.000Z
|
iso8601-local | 1969-12-31T19:00:00.000-05:00
|
Starting in MongoDB 4.4, 从MongoDB 4.4开始，--timeStampFormat no longer supports ctime. --timeStampFormat不再支持ctime。An example of ctime formatted date is: Wed Dec 31 18:17:54.811.ctime格式日期的一个例子是：Wed Dec 31 18:17:54.811。
--pidfilepath <path>
Specifies a file location to store the process ID (PID) of the 指定用于存储mongod process. mongod进程的进程ID(PID)的文件位置。The user running the 运行mongod or mongos process must be able to write to this path. mongod或mongos进程的用户必须能够写入此路径。If the 如果未指定--pidfilepath option is not specified, the process does not create a PID file. --pidfilepath选项，则进程不会创建PID文件。This option is generally only useful in combination with the 此选项通常仅与--fork选项结合使用。--fork option.
On Linux, PID file management is generally the responsibility of your distro's init system: usually a service file in the 在Linux上，PID文件管理通常由发行版的init系统负责：通常是/etc/init.d directory, or a systemd unit file registered with systemctl. /etc/init.d目录中的服务文件，或者是用systemctl注册的systemd单元文件。Only use the 如果您不使用这些init系统之一，请仅使用--pidfilepath option if you are not using one of these init systems. --pidfilepath选项。For more information, please see the respective Installation Guide for your operating system.有关详细信息，请参阅相应的操作系统安装指南。
On macOS, PID file management is generally handled by 在macOS上，PID文件管理通常由brew. brew处理。Only use the 只有在macOS系统上未使用--pidfilepath option if you are not using brew on your macOS system. For more information, please see the respective Installation Guide for your operating system.brew时，才使用--pidfilepath选项。有关详细信息，请参阅相应的操作系统安装指南。
--keyFile <file>
Specifies the path to a key file that stores the shared secret that MongoDB instances use to authenticate to each other in a sharded cluster or replica set. 指定密钥文件的路径，该密钥文件存储MongoDB实例用于在分片集群或副本集中相互验证的共享密钥。--keyFile implies --auth. --keyFile表示--auth。See Internal/Membership Authentication for more information.有关详细信息，请参阅内部/成员身份验证。
Starting in MongoDB 4.2, keyfiles for internal membership authentication use YAML format to allow for multiple keys in a keyfile. 从MongoDB 4.2开始，用于内部成员身份验证的密钥文件使用YAML格式，允许在密钥文件中包含多个密钥。The YAML format accepts content of:YAML格式接受以下内容：
The YAML format is compatible with the existing single-key keyfiles that use the text file format.YAML格式与使用文本文件格式的现有单键密钥文件兼容。
--setParameter <options>
Specifies one of the MongoDB parameters described in MongoDB Server Parameters. 指定MongoDB服务器参数中描述的MongoDB参数之一。You can specify multiple 可以指定多个setParameter fields.setParameter字段。
--nounixsocket
Disables listening on the UNIX domain socket. 禁用在UNIX域套接字上侦听。--nounixsocket applies only to Unix-based systems.仅适用于基于Unix的系统。
The mongod process always listens on the UNIX socket unless one of the following is true:mongod进程始终在UNIX套接字上侦听，除非以下情况之一为真：
--nounixsocketnet.bindIpnet.bindIplocalhost or its associated IP addresslocalhost或其关联的IP地址mongod installed from official .deb and .rpm packages have the bind_ip configuration set to 127.0.0.1 by default.mongod的bindip配置设置为127.0.0.1。
--unixSocketPrefix <path>
Default: /tmp
The path for the UNIX socket. UNIX套接字的路径。--unixSocketPrefix applies only to Unix-based systems.--unixSocketPrefix仅适用于基于Unix的系统。
If this option has no value, the 如果该选项没有值，mongod process creates a socket with /tmp as a prefix. mongod进程将创建一个前缀为/tmp的套接字。MongoDB creates and listens on a UNIX socket unless one of the following is true:MongoDB在UNIX套接字上创建和侦听，除非满足以下条件之一：
net.unixDomainSocket.enabled is false--nounixsocketnet.bindIpnet.bindIplocalhost or its associated IP addresslocalhost或其关联的IP地址--filePermissions <path>
Default: 0700
Sets the permission for the UNIX domain socket file.设置UNIX域套接字文件的权限。
--filePermissions applies only to Unix-based systems.仅适用于基于Unix的系统。
--fork
Enables a daemon mode that runs the 启用后台运行mongod process in the background. mongod进程的守护程序模式。By default 默认情况下，mongod does not run as a daemon: typically you will run mongod as a daemon, either by using --fork or by using a controlling process that handles the daemonization process (e.g. as with upstart and systemd).mongod不作为守护进程运行：通常，您将使用--fork或使用处理守护进程的控制进程（例如，使用upstart和systemd）来运行mongod作为守护进程。
Using the 使用--fork option requires that you configure log output for the mongod with one of the following:--fork选项需要使用以下选项之一配置mongod的日志输出：
The --fork option is not supported on Windows.--fork选项在Windows上不受支持。
--auth
Enables authorization to control user's access to database resources and operations. 启用授权以控制用户对数据库资源和操作的访问。When authorization is enabled, MongoDB requires all clients to authenticate themselves first in order to determine the access for the client.启用授权后，MongoDB要求所有客户端首先进行身份验证，以确定客户端的访问权限。
Configure users via the mongo shell. 通过mongo shell配置用户。If no users exist, the localhost interface will continue to have access to the database until you create the first user.如果不存在用户，localhost接口将继续访问数据库，直到您创建第一个用户。
--noauth
Disables authentication. 禁用身份验证。Currently the default. 当前为默认值。Exists for future compatibility and clarity.为了将来的兼容性和清晰度而存在。
--transitionToAuth
Allows the 允许mongod to accept and create authenticated and non-authenticated connections to and from other mongod and mongos instances in the deployment. mongod接受和创建与部署中其他mongod和mongos实例的已验证和未验证连接。Used for performing rolling transition of replica sets or sharded clusters from a no-auth configuration to internal authentication. 用于执行副本集或分片集群从无身份验证配置到内部身份验证的滚动转换。Requires specifying a internal authentication mechanism such as 需要指定内部身份验证机制，如--keyFile.--keyFile。
For example, if using keyfiles for internal authentication, the 例如，如果使用密钥文件进行内部身份验证，mongod creates an authenticated connection with any mongod or mongos in the deployment using a matching keyfile. mongod将使用匹配的密钥文件创建与部署中任何mongod或mongos的身份验证连接。If the security mechanisms do not match, the 如果安全机制不匹配，mongod utilizes a non-authenticated connection instead.mongod将使用未经身份验证的连接。
A 使用mongod running with --transitionToAuth does not enforce user access controls. Users may connect to your deployment without any access control checks and perform read, write, and administrative operations.--transitionToAuth运行的mongod不会强制用户访问控制。用户可以在不进行任何访问控制检查的情况下连接到您的部署，并执行读、写和管理操作。
A 使用内部身份验证而不使用mongod running with internal authentication and without --transitionToAuth requires clients to connect using user access controls. --transitionToAuth运行的mongod需要客户端使用用户访问控制进行连接。Update clients to connect to the 在没有mongod using the appropriate user prior to restarting mongod without --transitionToAuth.--transitionToAuth的情况下重新启动mongod之前，使用适当的用户更新客户端以连接到mongod。
--sysinfo
Returns diagnostic system information and then exits. 返回诊断系统信息，然后退出。The information provides the page size, the number of physical pages, and the number of available physical pages.该信息提供页面大小、物理页面数量和可用物理页面数量。
--notablescan
Forbids operations that require a collection scan. 禁止需要集合扫描的操作。See 有关更多信息，请参阅notablescan for additional information.notablescan。
--shutdown
The --shutdown option cleanly and safely terminates the mongod process. --shutdown选项干净安全地终止mongod进程。When invoking 使用此选项调用mongod with this option you must set the --dbpath option either directly or by way of the configuration file and the --config option.mongod时，必须直接或通过配置文件和--config选项设置--dbpath选项。
The --shutdown option is available only on Linux systems.--shutdownn选项仅在Linux系统上可用。
For additional ways to shut down, see also Stop 有关关闭的其他方法，请参阅停止mongod Processes.mongod进程。
--redactClientLogData
Available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。
A 使用mongod running with --redactClientLogData redacts any message accompanying a given log event before logging. --redactClientLogData运行的mongod会在日志记录之前对伴随给定日志事件的任何消息进行编辑。This prevents the 这防止mongod from writing potentially sensitive data stored on the database to the diagnostic log. mongod将数据库中存储的潜在敏感数据写入诊断日志。Metadata such as error or operation codes, line numbers, and source file names are still visible in the logs.错误或操作代码、行号和源文件名等元数据在日志中仍然可见。
Use 将--redactClientLogData in conjunction with Encryption at Rest and TLS/SSL (Transport Encryption) to assist compliance with regulatory requirements.--redactClientLogData与静止加密和TLS/SSL（传输加密）结合使用，以帮助遵守法规要求。
For example, a MongoDB deployment might store Personally Identifiable Information (PII) in one or more collections. 例如，MongoDB部署可能会在一个或多个集合中存储个人身份信息（PII）。The mongod logs events such as those related to CRUD operations, sharding metadata, etc. mongod记录与CRUD操作、分片元数据等相关的事件。It is possible that the mongod may expose PII as a part of these logging operations. mongod可能会将PII作为这些日志记录操作的一部分。A 使用mongod running with --redactClientLogData removes any message accompanying these events before being output to the log, effectively removing the PII.--redactClientLogData运行的mongod会在输出到日志之前删除伴随这些事件的任何消息，从而有效地删除PII。
Diagnostics on a 由于缺少与日志事件相关的数据，使用mongod running with --redactClientLogData may be more difficult due to the lack of data related to a log event. --redactClientLogData运行的mongod上的诊断可能会更加困难。See the process logging manual page for an example of the effect of 有关--redactClientLogData on log output.--redactClientLogData对日志输出的影响的示例，请参阅进程日志记录手册页面。
On a running 在正在运行的mongod, use setParameter with the redactClientLogData parameter to configure this setting.mongod上，使用setParameter和redactClientLogData参数来配置此设置。
--networkMessageCompressors <string>
Default: snappy,zstd,zlib
Specifies the default compressor(s) to use for communication between this 指定用于此mongod instance and:mongod实例与以下对象之间通信的默认压缩器：
mongoshOP_COMPRESSED message format.OP_COMPRESSED消息格式的驱动程序。MongoDB supports the following compressors:MongoDB支持以下压缩器：
In versions 3.6 and 4.0, mongod and mongos enable network compression by default with snappy as the compressor.
Starting in version 4.2, mongod and mongos instances default to both snappy,zstd,zlib compressors, in that order.
To disable network compression, set the value to disabled.
Messages are compressed when both parties enable network compression. 当双方启用网络压缩时，消息将被压缩。Otherwise, messages between the parties are uncompressed.否则，双方之间的消息将被解压缩。
If you specify multiple compressors, then the order in which you list the compressors matter as well as the communication initiator. 如果指定多个压缩器，那么列出压缩器的顺序以及通信启动器都很重要。For example, if 例如，如果mongosh specifies the following network compressors zlib,snappy and the mongod specifies snappy,zlib, messages between mongosh and mongod uses zlib.mongosh指定了以下网络压缩器zlib,snappy，而mongod指定了snappy,zlib，那么mongosh和mongod之间的消息将使用zlib。
If the parties do not share at least one common compressor, messages between the parties are uncompressed. 如果双方不共享至少一个公共压缩器，则双方之间的消息将被解压缩。For example, if 例如，如果mongosh specifies the network compressor zlib and mongod specifies snappy, messages between mongosh and mongod are not compressed.mongosh指定网络压缩器zlib，而mongod指定snappy，那么mongosh和mongod之间的消息不会被压缩。
--timeZoneInfo <path>
The full path from which to load the time zone database. 加载时区数据库的完整路径。If this option is not provided, then MongoDB will use its built-in time zone database.如果未提供此选项，MongoDB将使用其内置时区数据库。
The configuration file included with Linux and macOS packages sets the time zone database path to Linux和macOS软件包附带的配置文件默认将时区数据库路径设置为/usr/share/zoneinfo by default./usr/share/zoneinfo。
The built-in time zone database is a copy of the Olson/IANA time zone database. 内置时区数据库是奥尔森/IANA时区数据库的副本。It is updated along with MongoDB releases, but the time zone database release cycle differs from the MongoDB release cycle. 它随MongoDB版本一起更新，但时区数据库发布周期与MongoDB发布周期不同。The most recent release of the time zone database is available on our download site.时区数据库的最新版本可在下载网站上获得。
wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip unzip timezonedb-latest.zip mongod --timeZoneInfo timezonedb-2017b/
MongoDB uses the third party timelib library to provide accurate conversions between timezones. MongoDB使用第三方timelib库来提供时区之间的精确转换。Due to a recent update, 由于最近的更新，timelib could create inaccurate time zone conversions in older versions of MongoDB.timelib可能会在早期版本的MongoDB中创建不准确的时区转换。
To explicitly link to the time zone database in versions of MongoDB prior to 5.0, 4.4.7, 4.2.14, and 4.0.25, download the time zone database. and use the timeZoneInfo parameter.
--outputConfig
New in version 4.2.在版本4.2中新增。
Outputs the 将mongod instance's configuration options, formatted in YAML, to stdout and exits the mongod instance. mongod实例的配置选项（格式为YAML）输出到stdout并退出mongod示例。For configuration options that uses Externally Sourced Configuration File Values, 对于使用外部源配置文件值的配置选项，--outputConfig returns the resolved value for those options.--outputConfig将返回这些选项的解析值。
This may include any configured passwords or secrets previously obfuscated through the external source.这可能包括之前通过外部源混淆的任何配置的密码或机密。
For usage examples, see:有关用法示例，请参阅：
New in version 4.0.在版本4.0中新增。
--enableFreeMonitoring <runtime|on|off>
New in version 4.0.在版本4.0中新增。 Available for MongoDB Community Edition.可用于MongoDB社区版。
Enables or disables free MongoDB Cloud monitoring. 启用或禁用免费MongoDB云监控。--enableFreeMonitoring accepts the following values:接受以下值：
runtime |
|
on | |
off |
Once enabled, the free monitoring state remains enabled until explicitly disabled. 一旦启用，自由监视状态将保持启用状态，直到显式禁用。That is, you do not need to re-enable each time you start the server.也就是说，您不需要在每次启动服务器时重新启用。
For the corresponding configuration file setting, see cloud.monitoring.free.state.
--freeMonitoringTag <string>
New in version 4.0.在版本4.0中新增。 Available for MongoDB Community Edition.可用于MongoDB社区版。
Optional tag to describe environment context. 描述环境上下文的可选标记。The tag can be sent as part of the free MongoDB Cloud monitoring registration at start up.标签可以在启动时作为免费MongoDB Cloud监控注册的一部分发送。
For the corresponding configuration file setting, see 有关相应的配置文件设置，请参阅cloud.monitoring.free.tags.cloud.monitoring.free.tags。
--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>
Available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。
The LDAP server against which the mongod authenticates users or determines what actions a user is authorized to perform on a given database. mongod对用户进行身份验证或确定用户有权对给定数据库执行哪些操作的LDAP服务器。If the LDAP server specified has any replicated instances, you may specify the host and port of each replicated server in a comma-delimited list.如果指定的LDAP服务器具有任何复制实例，则可以在逗号分隔的列表中指定每个复一致性务器的主机和端口。
If your LDAP infrastructure partitions the LDAP directory over multiple LDAP servers, specify one LDAP server or any of its replicated instances to 如果LDAP基础结构将LDAP目录划分为多个LDAP服务器，请将一个LDAP服务器或其任何复制实例指定为--ldapServers. --ldapServers。MongoDB supports following LDAP referrals as defined in RFC 4511 4.1.10. MongoDB支持RFC 4511 4.1.10中定义的以下LDAP引用。Do not use 不要使用--ldapServers for listing every LDAP server in your infrastructure.--ldapServers列出基础结构中的每个LDAP服务器。
This setting can be configured on a running mongod using setParameter.
If unset, mongod cannot use LDAP authentication or authorization.
--ldapValidateLDAPServerConfig <boolean>
Available in MongoDB EnterpriseMongoDB Enterprise中提供
A flag that determines if the 一个标志，用于确定mongod instance checks the availability of the LDAP server(s) as part of its startup:mongod实例在启动时是否检查LDAP服务器的可用性：
true, the mongod instance performs the availability check and only continues to start up if the LDAP server is available.true，mongod实例将执行可用性检查，并且仅在LDAP服务器可用时才继续启动。false, the mongod instance skips the availability check; i.e. the instance starts up even if the LDAP server is unavailable.false，mongod实例将跳过可用性检查；即，即使LDAP服务器不可用，实例也会启动。--ldapQueryUser <string>
Available in MongoDB Enterprise only.仅在MongoDB Enterprise中可用。
The identity with which 当连接到LDAP服务器或在LDAP服务器上执行查询时，mongod binds as, when connecting to or performing queries on an LDAP server.mongod绑定为的标识。
Only required if any of the following are true:仅当以下任何一项为真时才需要：
username transformation.You must use --ldapQueryUser with --ldapQueryPassword.
If unset, mongod will not attempt to bind to the LDAP server.
This setting can be configured on a running mongod using setParameter.
Windows MongoDB deployments can use --ldapBindWithOSDefaults instead of --ldapQueryUser and --ldapQueryPassword. You cannot specify both --ldapQueryUser and --ldapBindWithOSDefaults at the same time.
Available in MongoDB Enterprise only.
The password used to bind to an LDAP server when using --ldapQueryUser. You must use --ldapQueryPassword with --ldapQueryUser.
If not set, mongod does not attempt to bind to the LDAP server.
You can configure this setting on a running mongod using setParameter.
Starting in MongoDB 4.4, the ldapQueryPasswordsetParameter command accepts either a string or an array of strings. If ldapQueryPassword is set to an array, MongoDB tries each password in order until one succeeds. Use a password array to roll over the LDAP account password without downtime.
Windows MongoDB deployments can use --ldapBindWithOSDefaults instead of --ldapQueryUser and --ldapQueryPassword. You cannot specify both --ldapQueryPassword and --ldapBindWithOSDefaults at the same time.
--ldapBindWithOSDefaults <bool>
Default: false
Available in MongoDB Enterprise for the Windows platform only.
Allows mongod to authenticate, or bind, using your Windows login credentials when connecting to the LDAP server.
Only required if:
username transformation.Use --ldapBindWithOSDefaults to replace --ldapQueryUser and --ldapQueryPassword.
--ldapBindMethod <string>
Default: simple
Available in MongoDB Enterprise only.
The method mongod uses to authenticate to an LDAP server. Use with --ldapQueryUser and --ldapQueryPassword to connect to the LDAP server.
--ldapBindMethod supports the following values:
If you specify sasl, you can configure the available SASL mechanisms using --ldapBindSaslMechanisms. mongod defaults to using DIGEST-MD5 mechanism.
--ldapBindSaslMechanisms <string>
Default: DIGEST-MD5
Available in MongoDB Enterprise only.
A comma-separated list of SASL mechanisms mongod can use when authenticating to the LDAP server. The mongod and the LDAP server must agree on at least one mechanism. The mongod dynamically loads any SASL mechanism libraries installed on the host machine at runtime.
Install and configure the appropriate libraries for the selected SASL mechanism(s) on both the mongod host and the remote LDAP server host. Your operating system may include certain SASL libraries by default. Defer to the documentation associated with each SASL mechanism for guidance on installation and configuration.
If using the GSSAPI SASL mechanism for use with Kerberos Authentication, verify the following for the mongod host machine:
LinuxKRB5_CLIENT_KTNAME environment variable resolves to the name of the client Linux Keytab Files for the host machine. For more on Kerberos environment variables, please defer to the Kerberos documentation.mongod to use when connecting to the LDAP server and execute LDAP queries.Windows--ldapBindWithOSDefaults to true to allow mongod to use the generated credentials when connecting to the Active Directory server and execute queries.Set --ldapBindMethod to sasl to use this option.
For a complete list of SASL mechanisms see the IANA listing. Defer to the documentation for your LDAP or Active Directory service for identifying the SASL mechanisms compatible with the service.
MongoDB is not a source of SASL mechanism libraries, nor is the MongoDB documentation a definitive source for installing or configuring any given SASL mechanism. For documentation and support, defer to the SASL mechanism library vendor or owner.
For more information on SASL, defer to the following resources:
--ldapTransportSecurity <string>
Default: tls
Available in MongoDB Enterprise only.
By default, mongod creates a TLS/SSL secured connection to the LDAP server.
For Linux deployments, you must configure the appropriate TLS Options in /etc/openldap/ldap.conf file. Your operating system's package manager creates this file as part of the MongoDB Enterprise installation, via the libldap dependency. See the documentation for TLS Options in the ldap.conf OpenLDAP documentation for more complete instructions.
For Windows deployment, you must add the LDAP server CA certificates to the Windows certificate management tool. The exact name and functionality of the tool may vary depending on operating system version. Please see the documentation for your version of Windows for more information on certificate management.
Set --ldapTransportSecurity to none to disable TLS/SSL between mongod and the LDAP server.
Setting --ldapTransportSecurity to none transmits plaintext information and possibly credentials between mongod and the LDAP server.
--ldapTimeoutMS <long>
Default: 10000
Available in MongoDB Enterprise only.
The amount of time in milliseconds mongod should wait for an LDAP server to respond to a request.
Increasing the value of --ldapTimeoutMS may prevent connection failure between the MongoDB server and the LDAP server, if the source of the failure is a connection timeout. Decreasing the value of --ldapTimeoutMS reduces the time MongoDB waits for a response from the LDAP server.
This setting can be configured on a running mongod using setParameter.
--ldapUserToDNMapping <string>
Available in MongoDB Enterprise only.
Maps the username provided to mongod for authentication to a LDAP Distinguished Name (DN). You may need to use --ldapUserToDNMapping to transform a username into an LDAP DN in the following scenarios:
LDAP authorization query template that requires a DN.--ldapUserToDNMapping expects a quote-enclosed JSON-string representing an ordered array of documents. Each document contains a regular expression match and either a substitution or ldapQuery template used for transforming the incoming username.
Each document in the array has the following form:
{
match: "<regex>"
substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}
| Example | ||
|---|---|---|
match | An ECMAScript-formatted regular expression (regex) to match against a provided username. Each parenthesis-enclosed section represents a regex capture group used by substitution or ldapQuery.
| "(.+)ENGINEERING""(.+)DBA"
|
substitution | An LDAP distinguished name (DN) formatting template that converts the authentication name matched by the The result of the substitution must be an RFC4514 escaped string. | "cn={0},ou=engineering, dc=example,dc=com"
|
ldapQuery | A LDAP query formatting template that inserts the authentication name matched by the match regex into an LDAP query URI encoded respecting RFC4515 and RFC4516. Each curly bracket-enclosed numeric value is replaced by the corresponding regex capture group extracted from the authentication username via the match expression. mongod executes the query against the LDAP server to retrieve the LDAP DN for the authenticated user. mongod requires exactly one returned result for the transformation to be successful, or mongod skips this transformation.
| "ou=engineering,dc=example, dc=com??one?(user={0})"
|
For each document in the array, you must use either substitution or ldapQuery. You cannot specify both in the same document.
When performing authentication or authorization, mongod steps through each document in the array in the given order, checking the authentication username against the match filter. If a match is found, mongod applies the transformation and uses the output for authenticating the user. mongod does not check the remaining documents in the array.
If the given document does not match the provided authentication name, mongod continues through the list of documents to find additional matches. If no matches are found in any document, or the transformation the document describes fails, mongod returns an error.
Starting in MongoDB 4.4, mongod also returns an error if one of the transformations cannot be evaluated due to networking or authentication failures to the LDAP server. mongod rejects the connection request and does not check the remaining documents in the array.
Starting in MongoDB 5.0, --ldapUserToDNMapping accepts an empty string "" or empty array [ ] in place of a mapping documnent. If providing an empty string or empty array to --ldapUserToDNMapping, MongoDB will map the authenticated username as the LDAP DN. Previously, providing an empty mapping document would cause mapping to fail.
The following shows two transformation documents. The first document matches against any string ending in @ENGINEERING, placing anything preceeding the suffix into a regex capture group. The second document matches against any string ending in @DBA, placing anything preceeding the suffix into a regex capture group.
"[
{
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})"
}
]"
A user with username alice@ENGINEERING.EXAMPLE.COM matches the first document. The regex capture group {0} corresponds to the string alice. The resulting output is the DN "cn=alice,ou=engineering,dc=example,dc=com".
A user with username bob@DBA.EXAMPLE.COM matches the second document. The regex capture group {0} corresponds to the string bob. The resulting output is the LDAP query "ou=dba,dc=example,dc=com??one?(user=bob)". mongod executes this query against the LDAP server, returning the result "cn=bob,ou=dba,dc=example,dc=com".
If --ldapUserToDNMapping is unset, mongod applies no transformations to the username when attempting to authenticate or authorize a user against the LDAP server.
This setting can be configured on a running mongod using the setParameter database command.
--ldapAuthzQueryTemplate <string>
Available in MongoDB Enterprise only.
A relative LDAP query URL formatted conforming to RFC4515 and RFC4516 that mongod executes to obtain the LDAP groups to which the authenticated user belongs to. The query is relative to the host or hosts specified in --ldapServers.
In the URL, you can use the following substituion tokens:
| Substitution Token | |
|---|---|
{USER} | Substitutes the authenticated username, or the transformed username if a username mapping is specified.
|
{PROVIDED_USER} | Substitutes the supplied username, i.e. before either authentication or
|
When constructing the query URL, ensure that the order of LDAP parameters respects RFC4516:
[ dn [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]
If your query includes an attribute, mongod assumes that the query retrieves a the DNs which this entity is member of.
If your query does not include an attribute, mongod assumes the query retrieves all entities which the user is member of.
For each LDAP DN returned by the query, mongod assigns the authorized user a corresponding role on the admin database. If a role on the on the admin database exactly matches the DN, mongod grants the user the roles and privileges assigned to that role. See the db.createRole() method for more information on creating roles.
This LDAP query returns any groups listed in the LDAP user object's memberOf attribute.
"{USER}?memberOf?base"
Your LDAP configuration may not include the memberOf attribute as part of the user schema, may possess a different attribute for reporting group membership, or may not track group membership through attributes. Configure your query with respect to your own unique LDAP configuration.
If unset, mongod cannot authorize users using LDAP.
This setting can be configured on a running mongod using the setParameter database command.
--storageEngine string
Default: wiredTiger
Starting in version 4.2, MongoDB removes the deprecated MMAPv1 storage engine.
Specifies the storage engine for the mongod database. Available values include:
wiredTiger | To specify the WiredTiger Storage Engine. |
inMemory | To specify the In-Memory Storage Engine. Available in MongoDB Enterprise only. |
If you attempt to start a mongod with a --dbpath that contains data files produced by a storage engine other than the one specified by --storageEngine, mongod will refuse to start.
--dbpath <path>
Default: /data/db on Linux and macOS, \data\db on Windows
The directory where the mongod instance stores its data.
If using the default configuration file included with a package manager installation of MongoDB, the corresponding storage.dbPath setting uses a different default.
The files in --dbpath must correspond to the storage engine specified in --storageEngine. If the data files do not correspond to --storageEngine, mongod will refuse to start.
--directoryperdb
Uses a separate directory to store data for each database. The directories are under the --dbpath directory, and each subdirectory name corresponds to the database name.
Not available for mongod instances that use the in-memory storage engine.
Starting in MongoDB 5.0, dropping the final collection in a database (or dropping the database itself) when --directoryperdb is enabled deletes the newly empty subdirectory for that database.
To change the --directoryperdb option for existing deployments:
For standalone instances:
mongodump on the existing mongod instance to generate a backup.mongod instance.--directoryperdb value andconfigure a new data directorymongod instance.mongorestore to populate the new data directory.For replica sets:
--directoryperdb value andconfigure a new data directory to that secondary member.--syncdelay <value>
Default: 60
Controls how much time can pass before MongoDB flushes data to the data files via an fsync operation.
Do not set this value on production systems. In almost every situation, you should use the default setting.
If you set --syncdelay to 0, MongoDB will not sync the memory mapped files to disk.
The mongod process writes data very quickly to the journal and lazily to the data files. --syncdelay has no effect on the journal files or journaling, but if --syncdelay is set to 0 the journal will eventually consume all available disk space. If you set --syncdelay to 0 for testing purposes, you should also set --nojournal to true.
Not available for mongod instances that use the in-memory storage engine.
--upgrade
Upgrades the on-disk data format of the files specified by the --dbpath to the latest version, if needed.
This option only affects the operation of the mongod if the data files are in an old format.
In most cases you should not set this value, so you can exercise the most control over your upgrade process. See the MongoDB release notes for more information about the upgrade process.
--repair
Runs a repair routine on all databases for a mongod instance.
Starting in MongoDB 5.0:
In MongoDB 4.4 and previous versions, the repair operation attempts to:
If you are running with journaling enabled, there is almost never any need to run repair since the server can use the journal files to restore the data files to a clean state automatically. However, you may need to run repair in cases where you need to recover from a disk-level data corruption.
mongod --repair if you have no other options. The operation removes and does not save any corrupt data during the repair process.Avoid running --repair against a replica set member:
mongod --repair against a replica set member and the operation modifies the data or the metadata, you must still perform a full resync in order for the member to rejoin the replica set.--repair, make a backup copy of the dbpath directory.--repair option.--journal
Enables the durability journal to ensure data files remain valid and recoverable. This option applies only when you specify the --dbpath option. mongod enables journaling by default.
Not available for mongod instances that use the in-memory storage engine.
If any voting member of a replica set uses the in-memory storage engine, you must set writeConcernMajorityJournalDefault to false.
Starting in version 4.2 (and 4.0.13 and 3.6.14 ), if a replica set member uses the in-memory storage engine(voting or non-voting) but the replica set has writeConcernMajorityJournalDefault set to true, the replica set member logs a startup warning.
--nojournal
Disables journaling. mongod enables journaling by default.
Not available for mongod instances that use the in-memory storage engine.
Starting in MongoDB 4.0, you cannot specify --nojournal option or storage.journal.enabled:
false for replica set members that use the WiredTiger storage engine.
--journalCommitInterval <value>
Default: 100
The maximum amount of time in milliseconds that the mongod process allows between journal operations. Values can range from 1 to 500 milliseconds. Lower values increase the durability of the journal, at the expense of disk performance.
On WiredTiger, the default journal commit interval is 100 milliseconds. Additionally, a write that includes or implies j:true will cause an immediate sync of the journal. For details or additional conditions that affect the frequency of the sync, see Journaling Process.
Not available for mongod instances that use the in-memory storage engine.
Known Issue in 4.2.0: The --journalCommitInterval is missing in 4.2.0.
--wiredTigerCacheSizeGB <float>
Defines the maximum size of the internal cache that WiredTiger will use for all data. The memory consumed by an index build (see maxIndexBuildMemoryUsageMegabytes) is separate from the WiredTiger cache memory.
Values can range from 0.25 GB to 10000 GB.
Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:
For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). Conversely, a system with a total of 1.25 GB of RAM will allocate 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).
In some instances, such as when running in a container, the database can have memory constraints that are lower than the total system memory. In such instances, this memory limit, rather than the total system memory, is used as the maximum RAM available.
To see the memory limit, see hostInfo.system.memLimitMB.
Avoid increasing the WiredTiger internal cache size above its default value.
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.
Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.
The --wiredTigerCacheSizeGB limits the size of the WiredTiger internal cache. The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. In addition, the operating system will use any free RAM to buffer file system blocks and file system cache.
To accommodate the additional consumers of RAM, you may have to decrease WiredTiger internal cache size.
The default WiredTiger internal cache size value assumes that there is a single mongod instance per machine. If a single machine contains multiple MongoDB instances, then you should decrease the setting to accommodate the other mongod instances.
If you run mongod in a container (e.g. lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set --wiredTigerCacheSizeGB to a value less than the amount of RAM available in the container. The exact amount depends on the other processes running in the container. See memLimitMB.
--wiredTigerMaxCacheOverflowFileSizeGB <float>
MongoDB deprecates the --wiredTigerMaxCacheOverflowFileSizeGB option. The option has no effect starting in MongoDB 4.4.
Specifies the maximum size (in GB) for the "lookaside (or cache overflow) table" file WiredTigerLAS.wt for MongoDB 4.2.1-4.2.x and 4.0.12-4.0.x. The file no longer exists starting in version 4.4.
The setting can accept the following values:
0 | The default value. If set to 0, the file size is unbounded.
|
| number >= 0.1 | The maximum size (in GB). If the WiredTigerLAS.wt file exceeds this size, mongod exits with a fatal assertion. You can clear the WiredTigerLAS.wt file and restart mongod.
|
To change the maximum size during runtime, use the wiredTigerMaxCacheOverflowSizeGB parameter.
Available starting in MongoDB 4.2.1 (and 4.0.12)
--wiredTigerJournalCompressor <compressor>
Default: snappy
Specifies the type of compression to use to compress WiredTiger journal data.
Available compressors are:
--wiredTigerDirectoryForIndexes
When you start mongod with --wiredTigerDirectoryForIndexes, mongod stores indexes and collections in separate subdirectories under the data (i.e. --dbpath) directory. Specifically, mongod stores the indexes in a subdirectory named index and the collection data in a subdirectory named collection.
By using a symbolic link, you can specify a different location for the indexes. Specifically, when mongod instance is notrunning, move the index subdirectory to the destination and create a symbolic link named index under the data directory to the new destination.
--wiredTigerCollectionBlockCompressor <compressor>
Default: snappy
Specifies the default compression for collection data. You can override this on a per-collection basis when creating collections.
Available compressors are:
--wiredTigerCollectionBlockCompressor affects all collections created. If you change the value of --wiredTigerCollectionBlockCompressor on an existing MongoDB deployment, all new collections will use the specified compressor. Existing collections will continue to use the compressor specified when they were created, or the default compressor at that time.
--wiredTigerIndexPrefixCompression <boolean>
Default: true
Enables or disables prefix compression for index data.
Specify true for --wiredTigerIndexPrefixCompression to enable prefix compression for index data, or false to disable prefix compression for index data.
The --wiredTigerIndexPrefixCompression setting affects all indexes created. If you change the value of --wiredTigerIndexPrefixCompression on an existing MongoDB deployment, all new indexes will use prefix compression. Existing indexes are not affected.
--replSet <setname>
Configures replication. Specify a replica set name as an argument to this set. All hosts in the replica set must have the same set name.
Starting in MongoDB 4.0,
--replSet cannot be used in conjunction with --nojournal.If your application connects to more than one replica set, each set must have a distinct name. Some drivers group replica set connections by replica set name.
--oplogSize <value>
Specifies a maximum size in megabytes for the replication operation log (i.e., the oplog).
Starting in MongoDB 4.0, the oplog can grow past its configured size limit to avoid deleting the majority commit point.
By default, the mongod process creates an oplog based on the maximum amount of space available. For 64-bit systems, the oplog is typically 5% of available disk space.
Once the mongod has created the oplog for the first time, changing the --oplogSize option will not affect the size of the oplog. To change the minimum oplog retention period after starting the mongod, use replSetResizeOplog. replSetResizeOplog enables you to resize the oplog dynamically without restarting the mongod process. To persist the changes made using replSetResizeOplog through a restart, update the value of --oplogSize.
See Oplog Size for more information.
--oplogMinRetentionHours <value>
New in version 4.4.在版本4.4中新增。 Specifies the minimum number of hours to preserve an oplog entry, where the decimal values represent the fractions of an hour. For example, a value of 1.5 represents one hour and thirty minutes.
The value must be greater than or equal to 0. A value of 0 indicates that the mongod should truncate the oplog starting with the oldest entries to maintain the configured maximum oplog size.
Defaults to 0.
A mongod started with --oplogMinRetentionHours only removes an oplog entry if:
The mongod has the following behavior when configured with a minimum oplog retention period:
mongod may continue to hold that disk space even if the oplog returns to its maximum size or is configured for a smaller maximum size. See Reducing Oplog Size Does Not Immediately Return Disk Space.mongod compares the system wall clock to an oplog entries creation wall clock time when enforcing oplog entry retention. Clock drift between cluster components may result in unexpected oplog retention behavior. See Clock Synchronization for more information on clock synchronization across cluster members.To change the minimum oplog retention period after starting the mongod, use replSetResizeOplog. replSetResizeOplog enables you to resize the oplog dynamically without restarting the mongod process. To persist the changes made using replSetResizeOplog through a restart, update the value of --oplogMinRetentionHours.
--enableMajorityReadConcern
Default: true
Configures support for "majority" read concern.
Starting in MongoDB 5.0, --enableMajorityReadConcern cannot be changed and is always set to true. In earlier versions of MongoDB, --enableMajorityReadConcern was configurable.
If you are using a three-member primary-secondary-arbiter (PSA)
architecture, the write concern "majority" can cause performance issues if a secondary is unavailable or lagging. See Mitigate Performance Issues with PSA Replica Set for advice on how to mitigate these issues.
--configsvr
Required if starting a config server.
Declares that this mongod instance serves as the config server of a sharded cluster. When running with this option, clients (i.e. other cluster components)
cannot write data to any database other than config and admin. The default port for a mongod with this option is 27019 and the default --dbpath directory is /data/configdb, unless specified.
When starting a MongoDB server with --configsvr, you must also specify a --replSet.
The use of the deprecated mirrored mongod instances as config servers (SCCC) is no longer supported.
The replica set config servers (CSRS) must run the WiredTiger storage engine.
The --configsvr option creates a local oplog.
Do not use the --configsvr option with --shardsvr. Config servers cannot be a shard server.
Do not use the --configsvr with the skipShardingConfigurationChecks parameter. That is, if you are temporarily starting the mongod as a standalone for maintenance operations, include the parameter skipShardingConfigurationChecks and exclude --configsvr. Once maintenance has completed, remove the skipShardingConfigurationChecks parameter and restart with --configsvr.
--configsvrMode <string>
Available in MongoDB 3.2 version only
If set to sccc, indicates that the config servers are deployed as three mirrored mongod instances, even if one or more config servers is also a member of a replica set. configsvrMode only accepts the value sccc.
If unset, config servers running as replica sets expect to use the "config server replica set" protocol for writing to config servers, rather than the "mirrored mongod" write protocol.
--shardsvr
Required if starting a shard server.
Configures this mongod instance as a shard in a sharded cluster. The default port for these instances is 27018.
When starting a MongoDB server with --shardsvr, you must also specify a --replSet.
Do not use the --shardsvr with the skipShardingConfigurationChecks parameter. That is, if you are temporarily starting the mongod as a standalone for maintenance operations, include the parameter skipShardingConfigurationChecks and exclude --shardsvr. Once maintenance has completed, remove the skipShardingConfigurationChecks parameter and restart with --shardsvr.
Configure mongod and mongos for TLS/SSL for full documentation of MongoDB's support.
--tlsMode <mode>
New in version 4.2.在版本4.2中新增。
Enables TLS used for all network connections. The argument to the --tlsMode option can be one of the following:
disabled | The server does not use TLS. |
allowTLS | Connections between servers do not use TLS. For incoming connections, the server accepts both TLS and non-TLS. |
preferTLS | Connections between servers use TLS. For incoming connections, the server accepts both TLS and non-TLS. |
requireTLS | The server uses and accepts only TLS encrypted connections. |
If --tlsCAFile or tls.CAFile is not specified and you are not using x.509 authentication, the system-wide CA certificate store will be used when connecting to an TLS-enabled server.
If using x.509 authentication, --tlsCAFile or tls.CAFile must be specified unless using --tlsCertificateSelector.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsCertificateKeyFile <filename>
New in version 4.2.在版本4.2中新增。 Specifies the .pem file that contains both the TLS certificate and key.
Starting with MongoDB 4.0 on macOS or Windows, you can use the --tlsCertificateSelector option to specify a certificate from the operating system's secure certificate store instead of a PEM key file. --tlsCertificateKeyFile and --tlsCertificateSelector options are mutually exclusive. You can only specify one.
--tlsCertificateKeyFile when TLS/SSL is enabled.On Windows or macOS, you must specify either --tlsCertificateKeyFile or --tlsCertificateSelector when TLS/SSL is enabled.
For Windows only, MongoDB 4.0 and later do not support encrypted PEM files. The mongod fails to start if it encounters an encrypted PEM file. To securely store and access a certificate for use with TLS on Windows, use --tlsCertificateSelector.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsCertificateKeyFilePassword <value>
New in version 4.2.在版本4.2中新增。
Specifies the password to de-crypt the certificate-key file (i.e. --tlsCertificateKeyFile). Use the --tlsCertificateKeyFilePassword option only if the certificate-key file is encrypted. In all cases, the mongod will redact the password from all logging and reporting output.
Starting in MongoDB 4.0:
--tlsCertificateKeyFilePassword option, MongoDB will prompt for a passphrase. See TLS/SSL Certificate Passphrase.--tlsCertificateKeyFilePassword option. Alternatively, you can use a certificate from the secure system store (see --tlsCertificateSelector) instead of a PEM file or use an unencrypted PEM file.mongod fails if it encounters an encrypted PEM file. Use --tlsCertificateSelector instead.For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--clusterAuthMode <option>
Default: keyFile
The authentication mode used for cluster authentication. If you use internal x.509 authentication, specify so here. This option can have one of the following values:
keyFile | Use a keyfile for authentication. Accept only keyfiles. |
sendKeyFile | For rolling upgrade purposes. Send a keyfile for authentication but can accept both keyfiles and x.509 certificates. |
sendX509 | For rolling upgrade purposes. Send the x.509 certificate for authentication but can accept both keyfiles and x.509 certificates. |
x509 | Recommended. Send the x.509 certificate for authentication and accept only x.509 certificates. |
If --tlsCAFile or tls.CAFile is not specified and you are not using x.509 authentication, the system-wide CA certificate store will be used when connecting to an TLS-enabled server.
If using x.509 authentication, --tlsCAFile or tls.CAFile must be specified unless using --tlsCertificateSelector.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsClusterFile <filename>
New in version 4.2.在版本4.2中新增。 Specifies the .pem file that contains the x.509 certificate-key file for membership authentication for the cluster or replica set.
Starting with MongoDB 4.0 on macOS or Windows, you can use the --tlsClusterCertificateSelector option to specify a certificate from the operating system's secure certificate store instead of a PEM key file. --tlsClusterFile and --tlsClusterCertificateSelector options are mutually exclusive. You can only specify one.
If --tlsClusterFile does not specify the .pem file for internal cluster authentication or the alternative --tlsClusterCertificateSelector, the cluster uses the .pem file specified in the --tlsCertificateKeyFile option or the certificate returned by the --tlsCertificateSelector.
If using x.509 authentication, --tlsCAFile or tls.CAFile must be specified unless using --tlsCertificateSelector.
Changed in version 4.4.在版本4.4中更改。
mongod / mongos logs a warning on connection if the presented x.509 certificate expires within 30 days of the mongod/mongos host system time. See x.509 Certificates Nearing Expiry Trigger Warnings for more information.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
For Windows only, MongoDB 4.0 and later do not support encrypted PEM files. The mongod fails to start if it encounters an encrypted PEM file. To securely store and access a certificate for use with membership authentication on Windows, use --tlsClusterCertificateSelector.
--tlsCertificateSelector <parameter>=<value>
New in version 4.2.在版本4.2中新增。 Available on Windows and macOS as an alternative to --tlsCertificateKeyFile. In version 4.0, see --sslCertificateSelector.
Specifies a certificate property in order to select a matching certificate from the operating system's certificate store to use for TLS.
The --tlsCertificateKeyFile and --tlsCertificateSelector options are mutually exclusive. You can only specify one.
--tlsCertificateSelector accepts an argument of the format <property>=<value> where the property can be one of the following:
| Property | Value type | |
|---|---|---|
subject | ASCII string | Subject name or common name on certificate |
thumbprint | hex string | A sequence of bytes, expressed as hexadecimal, used to identify a public key by its SHA-1 digest. The |
When using the system SSL certificate store, OCSP (Online Certificate Status Protocol) is used to validate the revocation status of certificates.
The mongod searches the operating system's secure certificate store for the CA certificates required to validate the full certificate chain of the specified TLS certificate. Specifically, the secure certificate store must contain the root CA and any intermediate CA certificates required to build the full certificate chain to the TLS certificate. Do not use --tlsCAFile or --tlsClusterCAFile to specify the root and intermediate CA certificate
For example, if the TLS/SSL certificate was signed with a single root CA certificate, the secure certificate store must contain that root CA certificate. If the TLS/SSL certificate was signed with an intermediate CA certificate, the secure certificate store must contain the intermedia CA certificate and the root CA certificate.
You cannot use the rotateCertificates command or the db.rotateCertificates() shell method when using net.tls.certificateSelector or --tlsCertificateSelector set to thumbprint
--tlsClusterCertificateSelector <parameter>=<value>
New in version 4.2.在版本4.2中新增。 Available on Windows and macOS as an alternative to --tlsClusterFile.
Specifies a certificate property in order to select a matching certificate from the operating system's certificate store to use for internal x.509 membership authentication.
--tlsClusterFile and --tlsClusterCertificateSelector options are mutually exclusive. You can only specify one.
--tlsClusterCertificateSelector accepts an argument of the format <property>=<value> where the property can be one of the following:
| Property | Value type | |
|---|---|---|
subject | ASCII string | Subject name or common name on certificate |
thumbprint | hex string | A sequence of bytes, expressed as hexadecimal, used to identify a public key by its SHA-1 digest. The |
The mongod searches the operating system's secure certificate store for the CA certificates required to validate the full certificate chain of the specified cluster certificate. Specifically, the secure certificate store must contain the root CA and any intermediate CA certificates required to build the full certificate chain to the cluster certificate. Do not use --tlsCAFile or --tlsClusterCAFile to specify the root and intermediate CA certificate.
For example, if the cluster certificate was signed with a single root CA certificate, the secure certificate store must contain that root CA certificate. If the cluster certificate was signed with an intermediate CA certificate, the secure certificate store must contain the intermedia CA certificate and the root CA certificate.
Changed in version 4.4.在版本4.4中更改。
mongod / mongos logs a warning on connection if the presented x.509 certificate expires within 30 days of the mongod/mongos host system time. See x.509 Certificates Nearing Expiry Trigger Warnings for more information.
--tlsClusterPassword <value>
New in version 4.2.在版本4.2中新增。 Specifies the password to de-crypt the x.509 certificate-key file specified with --tlsClusterFile. Use the --tlsClusterPassword option only if the certificate-key file is encrypted. In all cases, the mongod will redact the password from all logging and reporting output.
Starting in MongoDB 4.0:
--tlsClusterPassword option, MongoDB will prompt for a passphrase. See TLS/SSL Certificate Passphrase.--tlsClusterPassword option. Alternatively, you can either use a certificate from the secure system store (see --tlsClusterCertificateSelector) instead of a cluster PEM file or use an unencrypted PEM file.mongod fails if it encounters an encrypted PEM file. Use --tlsClusterCertificateSelector instead.For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsCAFile <filename>
New in version 4.2.在版本4.2中新增。
Specifies the .pem file that contains the root certificate chain from the Certificate Authority. Specify the file name of the .pem file using relative or absolute paths.
--tlsCertificateSelector and/or --tlsClusterCertificateSelector, do not use --tlsCAFile to specify the root and intermediate CA certificates. Store all CA certificates required to validate the full trust chain of the --tlsCertificateSelector and/or --tlsClusterCertificateSelector certificates in the secure certificate store.For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsClusterCAFile <filename>
New in version 4.2.在版本4.2中新增。
Specifies the .pem file that contains the root certificate chain from the Certificate Authority used to validate the certificate presented by a client establishing a connection. Specify the file name of the .pem file using relative or absolute paths. --tlsClusterCAFile requires that --tlsCAFile is set.
If --tlsClusterCAFile does not specify the .pem file for validating the certificate from a client establishing a connection, the cluster uses the .pem file specified in the --tlsCAFile option.
--tlsClusterCAFile lets you use separate Certificate Authorities to verify the client to server and server to client portions of the TLS handshake.
--tlsCertificateSelector and/or --tlsClusterCertificateSelector, do not use --tlsClusterCAFile to specify the root and intermediate CA certificates. Store all CA certificates required to validate the full trust chain of the --tlsCertificateSelector and/or --tlsClusterCertificateSelector certificates in the secure certificate store.For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsCRLFile <filename>
New in version 4.2.在版本4.2中新增。 For MongoDB 4.0 and earlier, see --sslCRLFile.
Specifies the .pem file that contains the Certificate Revocation List. Specify the file name of the .pem file using relative or absolute paths.
--sslCertificateSelector in MongoDB 4.0 and --tlsCertificateSelector in MongoDB 4.2+ to use the system SSL certificate store.enables the use of OCSP (Online Certificate Status Protocol) by default as an alternative to specifying a CRL file or using the system SSL certificate store.For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsAllowInvalidCertificates
New in version 4.2.在版本4.2中新增。
Bypasses the validation checks for TLS certificates on other servers in the cluster and allows the use of invalid certificates to connect.
If you specify --tlsAllowInvalidCertificates or tls.allowInvalidCertificates:
true when using x.509 authentication, an invalid certificate is only sufficient to establish a TLS connection but is insufficient for authentication.
When using the --tlsAllowInvalidCertificates setting, MongoDB logs a warning regarding the use of the invalid certificate.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsAllowInvalidHostnames
New in version 4.2.在版本4.2中新增。
Disables the validation of the hostnames in TLS certificates, when connecting to other members of the replica set or sharded cluster for inter-process authentication. This allows mongod to connect to other members if the hostnames in their certificates do not match their configured hostname.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsAllowConnectionsWithoutCertificates
New in version 4.2.在版本4.2中新增。
For clients that do not present certificates, mongod bypasses TLS/SSL certificate validation when establishing the connection.
For clients that present a certificate, however, mongod performs certificate validation using the root certificate chain specified by --tlsCAFile and reject clients with invalid certificates.
Use the --tlsAllowConnectionsWithoutCertificates option if you have a mixed deployment that includes clients that do not or cannot present certificates to the mongod.
For more information about TLS and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--tlsDisabledProtocols <protocol(s)>
New in version 4.2.在版本4.2中新增。
Prevents a MongoDB server running with TLS from accepting incoming connections that use a specific protocol or protocols. To specify multiple protocols, use a comma separated list of protocols.
--tlsDisabledProtocols recognizes the following protocols: TLS1_0, TLS1_1, TLS1_2, and TLS1_3.
TLS1_1 and leave both TLS1_0 and TLS1_2 enabled. You must disable at least one of the other two, for example, TLS1_0,TLS1_1.TLS1_0,TLS1_1.Starting in version 4.0, MongoDB disables the use of TLS 1.0 if TLS 1.1+ is available on the system. To enable the disabled TLS 1.0, specify none to --tlsDisabledProtocols. See Disable TLS 1.0.
Members of replica sets and sharded clusters must speak at least one protocol in common.
--tlsFIPSMode
New in version 4.2.在版本4.2中新增。
Directs the mongod to use the FIPS mode of the TLS library. Your system must have a FIPS compliant library to use the --tlsFIPSMode option.
FIPS-compatible TLS/SSL is available only in MongoDB Enterprise. See Configure MongoDB for FIPS for more information.
All SSL options are deprecated since 4.2. Use the TLS counterparts instead, as they have identical functionality to the SSL options. The SSL protocol is deprecated and MongoDB supports TLS 1.0 and later.
Configure mongod and mongos for TLS/SSL for full documentation of MongoDB's support.
--sslOnNormalPorts
Deprecated since version 2.6: Use --tlsMode requireTLS instead.
Enables TLS/SSL for mongod.
With --sslOnNormalPorts, a mongod requires TLS/SSL encryption for all connections on the default MongoDB port, or the port specified by --port. By default, --sslOnNormalPorts is disabled.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslMode <mode>
Deprecated since version 4.2: Use --tlsMode instead.
Enables TLS/SSL or mixed TLS/SSL used for all network connections. The argument to the --sslMode option can be one of the following:
disabled | The server does not use TLS/SSL. |
allowSSL | Connections between servers do not use TLS/SSL. For incoming connections, the server accepts both TLS/SSL and non-TLS/non-SSL. |
preferSSL | Connections between servers use TLS/SSL. For incoming connections, the server accepts both TLS/SSL and non-TLS/non-SSL. |
requireSSL | The server uses and accepts only TLS/SSL encrypted connections. |
Starting in version 3.4, if --tlsCAFile/net.tls.CAFile (or their aliases --sslCAFile/net.ssl.CAFile) is not specified and you are not using x.509 authentication, the system-wide CA certificate store will be used when connecting to an TLS/SSL-enabled server.
To use x.509 authentication, --tlsCAFile or net.tls.CAFile must be specified unless you are using --tlsCertificateSelector or --net.tls.certificateSelector.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslPEMKeyFile <filename>
Deprecated since version 4.2: Use --tlsCertificateKeyFile instead.
Specifies the .pem file that contains both the TLS/SSL certificate and key.
Starting with MongoDB 4.0 on macOS or Windows, you can use the --sslCertificateSelector option to specify a certificate from the operating system's secure certificate store instead of a PEM key file. --sslPEMKeyFile and --sslCertificateSelector options are mutually exclusive. You can only specify one.
--sslPEMKeyFile when TLS/SSL is enabled.On Windows or macOS, you must specify either --sslPEMKeyFile or --sslCertificateSelector when TLS/SSL is enabled.
For Windows only, MongoDB 4.0 and later do not support encrypted PEM files. The mongod fails to start if it encounters an encrypted PEM file. To securely store and access a certificate for use with TLS/SSL on Windows, use --sslCertificateSelector.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslPEMKeyPassword <value>
Deprecated since version 4.2: Use --tlsCertificateKeyFilePassword instead.
Specifies the password to de-crypt the certificate-key file (i.e. --sslPEMKeyFile). Use the --sslPEMKeyPassword option only if the certificate-key file is encrypted. In all cases, the mongod will redact the password from all logging and reporting output.
Starting in MongoDB 4.0:
--sslPEMKeyPassword option, MongoDB will prompt for a passphrase. See TLS/SSL Certificate Passphrase.--sslPEMKeyPassword option. Alternatively, you can use a certificate from the secure system store (see --sslCertificateSelector) instead of a PEM key file or use an unencrypted PEM file.mongod fails if it encounters an encrypted PEM file. Use --sslCertificateSelector instead.For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslClusterFile <filename>
Deprecated since version 4.2: Use --tlsClusterFile instead.
Specifies the .pem file that contains the x.509 certificate-key file for membership authentication for the cluster or replica set.
Starting with MongoDB 4.0 on macOS or Windows, you can use the --sslClusterCertificateSelector option to specify a certificate from the operating system's secure certificate store instead of a PEM key file. --sslClusterFile and --sslClusterCertificateSelector options are mutually exclusive. You can only specify one.
If --sslClusterFile does not specify the .pem file for internal cluster authentication or the alternative --sslClusterCertificateSelector, the cluster uses the .pem file specified in the --sslPEMKeyFile option or the certificate returned by the --sslCertificateSelector.
To use x.509 authentication, --tlsCAFile or net.tls.CAFile must be specified unless you are using --tlsCertificateSelector or --net.tls.certificateSelector.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
For Windows only, MongoDB 4.0 and later do not support encrypted PEM files. The mongod fails to start if it encounters an encrypted PEM file. To securely store and access a certificate for use with membership authentication on Windows, use --sslClusterCertificateSelector.
--sslCertificateSelector <parameter>=<value>
Deprecated since version 4.2: Use --tlsCertificateSelector instead.
New in version 4.0.在版本4.0中新增。 Available on Windows and macOS as an alternative to --tlsCertificateKeyFile.
Specifies a certificate property to select a matching certificate from the operating system's secure certificate store to use for TLS/SSL.
--sslPEMKeyFile and --sslCertificateSelector options are mutually exclusive. You can only specify one.
--sslCertificateSelector accepts an argument of the format <property>=<value> where the property can be one of the following:
| Property | Value type | |
|---|---|---|
subject | ASCII string | Subject name or common name on certificate |
thumbprint | hex string | A sequence of bytes, expressed as hexadecimal, used to identify a public key by its SHA-1 digest. The |
When using the system SSL certificate store, OCSP (Online Certificate Status Protocol) is used to validate the revocation status of certificates.
The mongod searches the operating system's secure certificate store for the CA certificates required to validate the full certificate chain of the specified TLS/SSL certificate. Specifically, the secure certificate store must contain the root CA and any intermediate CA certificates required to build the full certificate chain to the TLS/SSL certificate. Do not use --sslCAFile or --sslClusterCAFile to specify the root and intermediate CA certificate
For example, if the TLS/SSL certificate was signed with a single root CA certificate, the secure certificate store must contain that root CA certificate. If the TLS/SSL certificate was signed with an intermediate CA certificate, the secure certificate store must contain the intermedia CA certificate and the root CA certificate.
--sslClusterCertificateSelector <parameter>=<value>
Deprecated since version 4.2: Use --tlsClusterCertificateSelector instead.
New in version 4.0.在版本4.0中新增。 Available on Windows and macOS as an alternative to --sslClusterFile.
Specifies a certificate property to select a matching certificate from the operating system's secure certificate store to use for internal x.509 membership authentication.
--sslClusterFile and --sslClusterCertificateSelector options are mutually exclusive. You can only specify one.
--sslClusterCertificateSelector accepts an argument of the format <property>=<value> where the property can be one of the following:
| Property | Value type | |
|---|---|---|
subject | ASCII string | Subject name or common name on certificate |
thumbprint | hex string | A sequence of bytes, expressed as hexadecimal, used to identify a public key by its SHA-1 digest. The |
The mongod searches the operating system's secure certificate store for the CA certificates required to validate the full certificate chain of the specified cluster certificate. Specifically, the secure certificate store must contain the root CA and any intermediate CA certificates required to build the full certificate chain to the cluster certificate. Do not use --sslCAFile or --sslClusterCAFile to specify the root and intermediate CA certificate.
For example, if the cluster certificate was signed with a single root CA certificate, the secure certificate store must contain that root CA certificate. If the cluster certificate was signed with an intermediate CA certificate, the secure certificate store must contain the intermedia CA certificate and the root CA certificate.
--sslClusterPassword <value>
Deprecated since version 4.2: Use --tlsClusterPassword instead.
Specifies the password to de-crypt the x.509 certificate-key file specified with --sslClusterFile. Use the --sslClusterPassword option only if the certificate-key file is encrypted. In all cases, the mongod will redact the password from all logging and reporting output.
Starting in MongoDB 4.0:
--sslClusterPassword option, MongoDB will prompt for a passphrase. See TLS/SSL Certificate Passphrase.--sslClusterPassword option. Alternatively, you can either use a certificate from the secure system store (see --sslClusterCertificateSelector)
instead of a cluster PEM file or use an unencrypted PEM file.mongod fails if it encounters an encrypted PEM file. Use --sslClusterCertificateSelector instead.For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslCAFile <filename>
Deprecated since version 4.2: Use --tlsCAFile instead.
Specifies the .pem file that contains the root certificate chain from the Certificate Authority. Specify the file name of the .pem file using relative or absolute paths.
--sslCertificateSelector and/or --sslClusterCertificateSelector, do not use --sslCAFile to specify the root and intermediate CA certificates. Store all CA certificates required to validate the full trust chain of the --sslCertificateSelector and/or --sslClusterCertificateSelector certificates in the secure certificate store.For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslClusterCAFile <filename>
Deprecated since version 4.2: Use --tlsClusterCAFile instead.
Specifies the .pem file that contains the root certificate chain from the Certificate Authority used to validate the certificate presented by a client establishing a connection. Specify the file name of the .pem file using relative or absolute paths. --sslClusterCAFile requires that --sslCAFile is set.
If --sslClusterCAFile does not specify the .pem file for validating the certificate from a client establishing a connection, the cluster uses the .pem file specified in the --sslCAFile option.
--sslClusterCAFile lets you use separate Certificate Authorities to verify the client to server and server to client portions of the TLS handshake.
--sslCertificateSelector and/or --sslClusterCertificateSelector, do not use --sslClusterCAFile to specify the root and intermediate CA certificates. Store all CA certificates required to validate the full trust chain of the --sslCertificateSelector and/or --sslClusterCertificateSelector certificates in the secure certificate store.For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslCRLFile <filename>
Deprecated since version 4.2: Use --tlsCRLFile instead.
Specifies the .pem file that contains the Certificate Revocation List. Specify the file name of the .pem file using relative or absolute paths.
--sslCertificateSelector in MongoDB 4.0 and --tlsCertificateSelector in MongoDB 4.2+ to use the system SSL certificate store.enables the use of OCSP (Online Certificate Status Protocol) by default as an alternative to specifying a CRL file or using the system SSL certificate store.For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslAllowInvalidCertificates
Deprecated since version 4.2: Use --tlsAllowInvalidCertificates instead.
Bypasses the validation checks for TLS/SSL certificates on other servers in the cluster and allows the use of invalid certificates to connect.
Starting in MongoDB 4.2, if you specify --tlsAllowInvalidateCertificates or net.tls.allowInvalidCertificates: true when using x.509 authentication, an invalid certificate is only sufficient to establish a TLS connection but it is insufficient for authentication.
When using the --sslAllowInvalidCertificates setting, MongoDB logs a warning regarding the use of the invalid certificate.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslAllowInvalidHostnames
Deprecated since version 4.2: Use --tlsAllowInvalidHostnames instead.
Disables the validation of the hostnames in TLS/SSL certificates, when connecting to other members of the replica set or sharded cluster for inter-process authentication. This allows mongod to connect to other members if the hostnames in their certificates do not match their configured hostname.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslAllowConnectionsWithoutCertificates
Deprecated since version 4.2: Use --tlsAllowConnectionsWithoutCertificates instead.
For clients that do not present certificates, mongod bypasses TLS/SSL certificate validation when establishing the connection.
For clients that present a certificate, however, mongod performs certificate validation using the root certificate chain specified by --sslCAFile and reject clients with invalid certificates.
Use the --sslAllowConnectionsWithoutCertificates option if you have a mixed deployment that includes clients that do not or cannot present certificates to the mongod.
For more information about TLS/SSL and MongoDB, see Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients .
--sslDisabledProtocols <protocol(s)>
Deprecated since version 4.2: Use --tlsDisabledProtocols instead.
Prevents a MongoDB server running with TLS/SSL from accepting incoming connections that use a specific protocol or protocols. To specify multiple protocols, use a comma separated list of protocols.
--sslDisabledProtocols recognizes the following protocols: TLS1_0, TLS1_1, TLS1_2, and starting in version 4.0.4 (and 3.6.9 and 3.4.24), TLS1_3.
TLS1_1 and leave both TLS1_0 and TLS1_2 enabled. You must disable at least one of the other two, for example, TLS1_0,TLS1_1.TLS1_0,TLS1_1.Starting in version 4.0, MongoDB disables the use of TLS 1.0 if TLS 1.1+ is available on the system. To enable the disabled TLS 1.0, specify none to --sslDisabledProtocols. See Disable TLS 1.0.
Members of replica sets and sharded clusters must speak at least one protocol in common.
--sslFIPSMode
Deprecated since version 4.2: Use --tlsFIPSMode instead.
Directs the mongod to use the FIPS mode of the TLS/SSL library. Your system must have a FIPS compliant library to use the --sslFIPSMode option.
FIPS-compatible TLS/SSL is available only in MongoDB Enterprise. See Configure MongoDB for FIPS for more information.
--profile <level>
Default: 0
Configures the database profiler level. The following profiler levels are available:
| Level | |
|---|---|
0 | The profiler is off and does not collect any data. This is the default profiler level. |
1 | The profiler collects data for operations that take longer than the value of slowms.
|
2 | The profiler collects data for all operations. |
Profiling can impact performance and shares settings with the system log. Carefully consider any performance and security implications before configuring and enabling the profiler on a production deployment.
See Profiler Overhead for more information on potential performance degradation.
--slowms <integer>
Default: 100
The slow operation time threshold, in milliseconds. Operations that run for longer than this threshold are considered slow.
When logLevel is set to 0, MongoDB records slowoperations to the diagnostic log at a rate determined by slowOpSampleRate.
At higher logLevel settings, all operations appear in the diagnostic log regardless of their latency with the following exception: the logging of slow oplog entry messages by the secondaries. The secondaries log only the slow oplog entries; increasing the logLevel does not log all oplog entries.
For mongod instances, --slowms affects the diagnostic log and, if enabled, the profiler.
--slowOpSampleRate <double>
Default: 1.0
The fraction of slow operations that should be profiled or logged. --slowOpSampleRate accepts values between 0 and 1, inclusive.
--slowOpSampleRate does not affect the slow oplog entry logging by the secondary members of a replica set. Secondary members log all oplog entries that take longer than the slow operation threshold regardless of the --slowOpSampleRate.
For mongod instances, --slowOpSampleRate affects the diagnostic log and, if enabled, the profiler.
--auditCompressionMode
New in version 5.3.在版本5.3中新增。
Specifies the compression mode for audit log encryption. You must also enable audit log encryption using either --auditEncryptionKeyUID or --auditLocalKeyFile.
--auditCompressionMode can be set to one of these values:
zstd | Use the zstd algorithm to compress the audit log. |
none (default) | Do not compress the audit log. |
Available only in MongoDB Enterprise. MongoDB Enterprise and Atlas have different configuration requirements.
--auditDestination
Enables auditing and specifies where mongod sends all audit events.
--auditDestination can have one of the following values:
syslog | Output the audit events to syslog in JSON format. Not available on Windows. Audit messages have a syslog severity level of The syslog message limit can result in the truncation of audit messages. The auditing system will neither detect the truncation nor error upon its occurrence. |
console | Output the audit events to stdout in JSON format. |
file | Output the audit events to the file specified in --auditPath in the format specified in --auditFormat.
|
Available only in MongoDB Enterprise and MongoDB Atlas.
--auditEncryptionKeyUID
New in version 5.3.在版本5.3中新增。
Specifies the unique identifier of the Key Management Interoperability Protocol (KMIP) key for audit log encryption.
You cannot use --auditEncryptionKeyUID and --auditLocalKeyFile together.
Available only in MongoDB Enterprise. MongoDB Enterprise and Atlas have different configuration requirements.
--auditFormat
Specifies the format of the output file for auditing if --auditDestination is file. The --auditFormat option can have one of the following values:
JSON | Output the audit events in JSON format to the file specified in --auditPath.
|
BSON | Output the audit events in BSON binary format to the file specified in --auditPath.
|
Printing audit events to a file in JSON format degrades server performance more than printing to a file in BSON format.
Available only in MongoDB Enterprise and MongoDB Atlas.
--auditLocalKeyFile
New in version 5.3.在版本5.3中新增。
Specifies the path and file name for a local audit key file for audit log encryption.
Only use --auditLocalKeyFile for testing because the key is not secured. To secure the key, use --auditEncryptionKeyUID and an external Key Management Interoperability Protocol (KMIP) server.
You cannot use --auditLocalKeyFile and --auditEncryptionKeyUID together.
Available only in MongoDB Enterprise. MongoDB Enterprise and Atlas have different configuration requirements.
--auditPath
Specifies the output file for auditing if --auditDestination has value of file. The --auditPath option can take either a full path name or a relative path name.
Available only in MongoDB Enterprise and MongoDB Atlas.
--auditFilter
Specifies the filter to limit the types of operations the audit system records. The option takes a string representation of a query document of the form:
{ <field1>: <expression1>, ... }
The <field> can be any field in the audit message, including fields returned in the param document. The <expression> is a query condition expression.
To specify an audit filter, enclose the filter document in single quotes to pass the document as a string.
To specify the audit filter in a configuration file, you must use the YAML format of the configuration file.
Available only in MongoDB Enterprise and MongoDB Atlas.
MongoDB Enterprise on macOS does not include support for SNMP due to SERVER-29352.
--snmp-disabled
Disables SNMP access to mongod. The option is incompatible with --snmp-subagent and --snmp-master.
New in version 4.0.6.在版本4.0.6中新增。
--snmp-subagent
Runs SNMP as a subagent. The option is incompatible with --snmp-disabled.
--snmp-master
Runs SNMP as a master. The option is incompatible with --snmp-disabled.
--inMemorySizeGB <float>
Default: 50% of physical RAM less 1 GB
Changed in version 3.4.在版本3.4中更改。
Maximum amount of memory to allocate for in-memory storage engine data, including indexes, oplog if the mongod is part of replica set, replica set or sharded cluster metadata, etc.
By default, the in-memory storage engine uses 50% of physical RAM minus 1 GB.
Available in MongoDB Enterprise only.
--enableEncryption
Default: false
Enables encryption for the WiredTiger storage engine. This option must be enabled in order to pass in encryption keys and configurations.
Available in MongoDB Enterprise only.
--encryptionCipherMode <string>
Default: AES256-CBC
The cipher mode to use for encryption at rest:
| Mode | |
|---|---|
AES256-CBC | 256-bit Advanced Encryption Standard in Cipher Block Chaining Mode |
AES256-GCM | 256-bit Advanced Encryption Standard in Galois/Counter Mode
AES256-GCM. This cipher is now available only on Linux.
|
Available in MongoDB Enterprise only.
--encryptionKeyFile <string>
The path to the local keyfile when managing keys via process other than KMIP. Only set when managing keys via process other than KMIP. If data is already encrypted using KMIP, MongoDB will throw an error.
The keyfile can contain only a single key. The key is either a 16 or 32 character string.
Requires --enableEncryption.
Available in MongoDB Enterprise only.
--kmipKeyIdentifier <string>
Unique KMIP identifier for an existing key within the KMIP server. Include to use the key associated with the identifier as the system key. You can only use the setting the first time you enable encryption for the mongod instance. Requires --enableEncryption.
If unspecified, MongoDB will request that the KMIP server create a new key to utilize as the system key.
If the KMIP server cannot locate a key with the specified identifier or the data is already encrypted with a key, MongoDB will throw an error
Available in MongoDB Enterprise only.
--kmipRotateMasterKey <boolean>
Default: false
If true, rotate the master key and re-encrypt the internal keystore.
Available in MongoDB Enterprise only.
--kmipServerName <string>
Hostname or IP address of the KMIP server to connect to. Requires --enableEncryption.
Starting in MongoDB 4.2.1 (and 4.0.14), you can specify multiple KMIP servers as a comma-separated list, e.g. server1.example.com,server2.example.com. On startup, the mongod will attempt to establish a connection to each server in the order listed, and will select the first server to which it can successfully establish a connection. KMIP server selection occurs only at startup.
When connecting to a KMIP server, the mongod verifies that the specified --kmipServerName matches the Subject Alternative Name SAN (or, if SAN is not present, the Common Name CN) in the certificate presented by the KMIP server. If SAN is present, mongod does not match against the CN. If the hostname does not match the SAN (or CN), the mongod will fail to connect.
Starting in MongoDB 4.2, when performing comparison of SAN, MongoDB supports comparison of DNS names or IP addresses. In previous versions, MongoDB only supports comparisons of DNS names.
Available in MongoDB Enterprise only.
--kmipPort <number>
Default: 5696
Port number to use to communicate with the KMIP server. Requires --kmipServerName. Requires --enableEncryption.
If specifying multiple KMIP servers with --kmipServerName, the mongod will use the port specified with --kmipPort for all provided KMIP servers.
Available in MongoDB Enterprise only.
--kmipConnectRetries <number>
Default: 0
New in version 4.4.在版本4.4中新增。
How many times to retry the initial connection to the KMIP server. Use together with --kmipConnectTimeoutMS to control how long the mongod waits for a response between each retry.
Available in MongoDB Enterprise only.
--kmipConnectTimeoutMS <number>
Default: 5000
New in version 4.4.在版本4.4中新增。
Timeout in milliseconds to wait for a response from the KMIP server. If the --kmipConnectRetries setting is specified, the mongod will wait up to the value specified with --kmipConnectTimeoutMS for each retry.
Value must be 1000 or greater.
Available in MongoDB Enterprise only.
--kmipClientCertificateSelector <string>
New in version 4.0.在版本4.0中新增。 (and 4.2.15, 4.4.7, and 5.0)
Available on Windows and macOS as an alternative to --kmipClientCertificateFile.
--kmipClientCertificateFile and --kmipClientCertificateSelector options are mutually exclusive. You can only specify one.
Specifies a certificate property in order to select a matching certificate from the operating system's certificate store to authenticate MongoDB to the KMIP server.
--kmipClientCertificateSelector accepts an argument of the format <property>=<value> where the property can be one of the following:
| Property | Value type | |
|---|---|---|
subject | ASCII string | Subject name or common name on certificate |
thumbprint | hex string | A sequence of bytes, expressed as hexadecimal, used to identify a public key by its SHA-1 digest. The |
Available in MongoDB Enterprise only.
--kmipClientCertificateFile <string>
String containing the path to the client certificate used for authenticating MongoDB to the KMIP server. Requires that a --kmipServerName be provided.
Starting in 4.0, on macOS or Windows, you can use a certificate from the operating system's secure store instead of a PEM key file. See --kmipClientCertificateSelector.
Available in MongoDB Enterprise only.
--kmipClientCertificatePassword <string>
The password (if one exists) for the client certificate passed into --kmipClientCertificateFile. Is used for authenticating MongoDB to the KMIP server. Requires that a --kmipClientCertificateFile be provided.
Available in MongoDB Enterprise only.
--kmipServerCAFile <string>
Path to CA File. Used for validating secure client connection to KMIP server.
Starting in 4.0, on macOS or Windows, you can use a certificate from the operating system's secure store instead of a PEM key file. See --kmipClientCertificateSelector. When using the secure store, you do not need to, but can, also specify the --kmipServerCAFile.
--kmipActivateKeys <boolean>
Default: true
New in version 5.3.在版本5.3中新增。
Activates all newly created KMIP keys upon creation and then periodically checks those keys are in an active state.
When --kmipActivateKeys is true and you have existing keys on a KMIP server, the key must be activated first or the mongod node will fail to start.
If the key being used by the mongod transitions into a non-active state, the mongod node will shut down unless kmipActivateKeys is false. To ensure you have an active key, rotate the KMIP master key by using --kmipRotateMasterKey.
--kmipKeyStatePollingSeconds <integer>
Default: 900 seconds
New in version 5.3.在版本5.3中新增。
Frequency in seconds at which mongod polls the KMIP server for active keys.
To disable disable polling, set the value to -1.
--eseDatabaseKeyRollover
New in version 4.2.在版本4.2中新增。
Roll over the encrypted storage engine database keys configured with AES256-GCM cipher.
When mongod instance is started with this option, the instance rotates the keys and exits.
Available in MongoDB Enterprise only.