Run-time Database Configuration
On this page
The command line and configuration file interfaces provide MongoDB administrators with a large number of options and settings for controlling the operation of the database system. This document provides an overview of common configurations and examples of best-practice configurations for common use cases.
While both interfaces provide access to the same collection of options and settings, this document primarily uses the configuration file interface. If you installed MongoDB with a package manager such as
apt on Linux, or
brew on macOS, a default configuration file has been provided as part of your installation:
On Linux, a default
/etc/mongod.confconfiguration file is included when using a package manager to install MongoDB.
On Windows, a default
<install directory>/bin/mongod.cfgconfiguration file is included during the installation.
On macOS, a default
/usr/local/etc/mongod.confconfiguration file is included when installing from MongoDB’s official Homebrew tap.
For package installations of MongoDB on Linux or macOS, an initialization script which uses this default configuration file is also provided. This initialization script can be used to start the mongod on these platforms in the following manner:
- On Linux systems that use the systemd init system (the
sudo systemctl start mongod
- On Linux systems that use the SystemV init init system (the
sudo service mongod start
- On macOS, using the
brew services start firstname.lastname@example.org
If you installed MongoDB using a
ZIP file, you will need to create your own configuration file. A basic example configuration can be found later in this document. Once you have created a configuration file, you can start a MongoDB instance with this configuration file by using either the --config or -f options to mongod:
mongod --config /etc/mongod.conf mongod -f /etc/mongod.conf
Modify the values in the
/etc/mongod.conf file on your system to control the configuration of your database instance.
Consider the following basic configuration:
processManagement: fork: true net: bindIp: 127.0.0.1 port: 27017 storage: dbPath: /var/lib/mongo systemLog: destination: file path: "/var/log/mongodb/mongod.log" logAppend: true storage: journal: enabled: true
For most standalone servers, this is a sufficient base configuration. It makes several assumptions, but consider the following explanation:
127.0.0.1, which forces the server to only listen for requests on the localhost IP. Only bind to secure interfaces that the application-level systems can access with access control provided by system network filtering (i.e. “firewall”).
27017, which is the default MongoDB port for database instances. MongoDB can bind to any port. You can also filter access based on port using network filtering tools.
UNIX-like systems require superuser privileges to attach processes to ports lower than 1024.
true. This disables all but the most critical entries in output/log file, and is not recommended for production systems. If you do set this option, you can use setParameter to modify this setting during run time.
/var/lib/mongo, which specifies where MongoDB will store its data files.
If you installed MongoDB on Linux using a package manager, such as
apt , the
/etc/mongod.conf file provided with your MongoDB installation sets the following default
dbPath , depending on your Linux distro:
|Platform||Package Manager||Default |
|RHEL / CentOS and Amazon|
|Ubuntu and Debian|
The user account that mongod runs under will need read and write access to this directory.
true, which enables journaling. Journaling ensures single instance write-durability. 64-bit builds of mongod enable journaling by default. Thus, this setting may be redundant.
Given the default configuration, some of these values may be redundant. However, in many situations explicitly stating the configuration increases overall system intelligibility.
The following configuration options are useful for limiting access to a mongod instance:
net: bindIp: 127.0.0.1,10.8.0.10,192.168.4.24,/tmp/mongod.sock security: authorization: enabled
- This example provides four values to the bindIp option:
127.0.0.1, the localhost interface;
10.8.0.10, a private IP address typically used for local networks and VPN interfaces;
192.168.4.24, a private network interface typically used for local networks; and
/tmp/mongod.sock, a Unix domain socket path.
Because production MongoDB instances need to be accessible from multiple database servers, it is important to bind MongoDB to multiple interfaces that are accessible from your application servers. At the same time it’s important to limit these interfaces to interfaces controlled and protected at the network layer.
- Setting this option to
trueenables the authorization system within MongoDB. If enabled you will need to log in by connecting over the
localhostinterface for the first time to create user credentials.
- Setting this option to
replication: replSetName: set0
Use descriptive names for sets. Once configured, use the mongo shell to add hosts to the replica set.
security: keyFile: /srv/mongodb/keyfile
Setting keyFile enables authentication and specifies a key file for the replica set member use to when authenticating to each other. The content of the key file is arbitrary, but must be the same on all members of the replica set and mongos instances that connect to the set. The keyfile must be less than one kilobyte in size and may only contain characters in the base64 set and the file must not have group or “world” permissions on UNIX systems.
Changed in version 3.4: Starting in version 3.4, MongoDB removes support for mirrored config servers and config servers must be deployed as a replica set.
sharding: clusterRole: configsvr net: bindIp: 10.8.0.12 port: 27001 replication: replSetName: csRS
sharding: clusterRole: shardsvr replication: replSetName: shardA
If running as a replica set, initiate the shard replica set and add members.
sharding: configDB: csRS/10.8.0.12:27001
You can specify additional members of the config server replica set by specifying hostnames and ports in the form of a comma separated list after the replica set name.
In many cases running multiple instances of mongod on a single system is not recommended. On some types of deployments  and for testing purposes you may need to run more than one mongod on a single system.
In these cases, use a base configuration for each instance, but consider the following configuration values:
storage: dbPath: /var/lib/mongo/db0/ processManagement: pidFilePath: /var/lib/mongo/db0.pid
The dbPath value controls the location of the mongod instance’s data directory. Ensure that each database has a distinct and well labeled data directory. The pidFilePath controls where mongod process places it’s process id file. As this tracks the specific mongod file, it is crucial that file be unique and well labeled to make it easy to start and stop these processes.
Create additional init scripts and/or adjust your existing MongoDB configuration and init script as needed to control these processes.
|||Single-tenant systems with SSD or other high performance disks may provide acceptable performance levels for multiple mongod instances. Additionally, you may find that multiple databases with small working sets may function acceptably on a single system.|
The following configuration options control various mongod behaviors for diagnostic purposes:
operationProfiling.mode sets the database profiler level. The profiler is not active by default because of the possible impact on the profiler itself on performance. Unless this setting is on, queries are not profiled.
operationProfiling.slowOpThresholdMs configures the threshold which determines whether a query is “slow” for the purpose of the logging system and the profiler. The default value is 100 milliseconds. Set to a lower value if the logging system and the database profiler do not return useful results or set to a higher value to only log the longest running queries.
For MongoDB 3.6 deployments, starting in version 3.6.11, secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages are logged for the secondaries in the diagnostic log under the REPL component with the text
applied op: <oplog entry> took <num>ms . These slow oplog entries depend only on the slow operation threshold. They do not depend on the log levels (either at the system or component level), or the profiling level, or the slow operation sample rate. The profiler does not capture slow oplog entries.
- systemLog.verbosity controls the amount of logging output that mongod write to the log. Only use this option if you are experiencing an issue that is not reflected in the normal logging level.
Starting in MongoDB 3.0, you can also specify verbosity level for specific components using the
systemLog.component.<name>.verbosity setting. For the available components, see component verbosity settings.