On this page
mongod
On this page
Synopsis
mongod
is the primary daemon process for the MongoDB system. 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
. These command line options are primarily useful for testing: In common operation, use the configuration file options to control the behavior of your database.
Options
Core Options
--config
<filename>
,
-f
<filename>
-
Specifies a configuration file for runtime configuration options. The configuration file is the preferred method for runtime configuration of 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. The mongod instance does not support configuration files with non-ASCII encoding, including UTF-8.
--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
.)
--quiet
-
Runs mongod in a quiet mode that attempts to limit the amount of output.
This option suppresses:
- output from database commands
- replication activity
- connection accepted events
- connection closed events
--port
<port>
-
Default:
- 27017 if
mongod
is not a shard member or a config server member - 27018 if
mongod
is ashard member
- 27019 if
mongod
is aconfig server member
The TCP port on which the MongoDB instance listens for client connections.
- 27017 if
--bind_ip
<ip address>
-
Default: localhost
Note
Starting in MongoDB 3.6, mongod bind to localhost (
127.0.0.1
) by default. See Default Bind to Localhost.The IP addresses and/or full Unix domain socket paths on which mongod should listen for client connections. You may attach mongod to any interface. To bind to multiple addresses, enter a list of comma-separated values.
Example
localhost,/tmp/mongod.sock
You can specify both IPv4 and IPv6 addresses, or hostnames that resolve to an IPv4 or IPv6 address.
Example
localhost, 2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513
Note
If specifying an IPv6 address or a hostname that resolves to an IPv6 address to
--bind_ip
, you must start mongod with--ipv6
to enable IPv6 support. Specifying an IPv6 address to--bind_ip
does not enable IPv6 support.If specifying a link-local IPv6 address (
fe80::/10
), you must append the zone index to that address (i.e.fe80::<address>%<adapter-name>
).Example
localhost,fe80::a00:27ff:fee0:1fcf%enp0s3
Tip
To avoid downtime, give each config server a logical DNS name (unrelated to the server’s physical or virtual hostname). Without logical DNS names, moving or renaming a config server requires shutting down every
mongod
andmongos
instance in the sharded cluster.Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
To bind to all IPv4 addresses, enter
0.0.0.0
.To bind to all IPv4 and IPv6 addresses, enter
0.0.0.0,::
or alternatively, use thenet.bindIpAll
setting.Note
--bind_ip
and--bind_ip_all
are mutually exclusive. Specifying both options causes mongod to throw an error and terminate.
--bind_ip_all
-
New in version 3.6.
If specified, the mongod instance binds to all IPv4 addresses (i.e.
0.0.0.0
). If mongod starts with--ipv6
,--bind_ip_all
also binds to all IPv6 addresses (i.e.::
).mongod only supports IPv6 if started with
--ipv6
. Specifying--bind_ip_all
alone does not enable IPv6 support.Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
Alternatively, you can set the
--bind_ip
option to0.0.0.0,::
to bind to all IP addresses.Note
--bind_ip
and--bind_ip_all
are mutually exclusive. That is, you can specify one or the other, but not both.
--clusterIpSourceWhitelist
<string>
-
New in version 3.6.
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, themongos
instances. Themongod
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 themongod
ormongos
.--clusterIpSourceWhitelist
has no effect on amongod
started without authentication.--clusterIpSourceWhitelist
accepts multiple comma-separated IPv4/6 addresses or Classless Inter-Domain Routing (CIDR ) ranges:mongod --clusterIpSourceWhitelist 192.0.2.0/24,127.0.0.1,::1
Important
Ensure
--clusterIpSourceWhitelist
includes the IP address or CIDR ranges that include the IP address of each replica set member ormongos
in the deployment to ensure healthy communication between cluster components.
--ipv6
-
Enables IPv6 support. mongod disables IPv6 support by default.
Setting
--ipv6
does not direct the mongod to listen on any local IPv6 addresses or interfaces. To configure the mongod to listen on an IPv6 interface, you must either:- Configure
--bind_ip
with one or more IPv6 addresses or hostnames that resolve to IPv6 addresses, or - Set
--bind_ip_all
totrue
.
- Configure
--listenBacklog
<number>
-
Default: Target system
SOMAXCONN
constantNew in version 3.6.
The maximum number of connections that can exist in the listen queue.
Warning
Consult your local system’s documentation to understand the limitations and configuration requirements before using this parameter.
Important
To prevent undefined behavior, specify a value for this parameter between
1
and the local systemSOMAXCONN
constant.The default value for the
listenBacklog
parameter is set at compile time to the target systemSOMAXCONN
constant.SOMAXCONN
is the maximum valid value that is documented for the backlog parameter to the listen system call.Some systems may interpret
SOMAXCONN
symbolically, and others numerically. The actual listen backlog applied in practice may differ from any numeric interpretation of theSOMAXCONN
constant or argument to--listenBacklog
, and may also be constrained by system settings likenet.core.somaxconn
on Linux.Passing a value for the
listenBacklog
parameter that exceeds theSOMAXCONN
constant for the local system is, by the letter of the standards, undefined behavior. 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 thelistenBacklog
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.
--maxConns
<number>
-
The maximum number of simultaneous connections that mongod will accept. 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.
Note
Changed in version 2.6: MongoDB removed the upward limit on the
maxIncomingConnections
setting.
--logpath
<path>
-
Sends all diagnostic logging information to a log file instead of to standard output or to the host’s syslog system. MongoDB creates the log file at the path you specify.
By default, MongoDB will move any existing log file rather than overwrite it. To instead append to the log file, set the
--logappend
option.
--syslog
-
Sends all logging output to the host’s syslog system rather than to standard output or to a log file. , as with
--logpath
.The
--syslog
option is not supported on Windows.Warning
The
syslog
daemon generates timestamps when it logs a message, not when MongoDB issues the message. This can lead to misleading timestamps for log entries, especially when the system is under heavy load. We recommend using the--logpa