mongod

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

--help , -h

Returns information on the options and use of mongod.

--version

Returns the mongod release number.

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

The TCP port on which the MongoDB instance listens for client connections.

--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 and mongos 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 the net.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 to 0.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, 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.

--clusterIpSourceWhitelist has no effect on a mongod 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 or mongos 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 to true.
--listenBacklog <number>

Default: Target system SOMAXCONN constant

New 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 system SOMAXCONN constant.

The default value for the listenBacklog parameter is set at compile time to the target system SOMAXCONN 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 the SOMAXCONN constant or argument to --listenBacklog, and may also be constrained by system settings like net.core.somaxconn on Linux.

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

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