Run-time Database Configuration

The command line and configurationfile interfaces provide MongoDBadministrators with a large number of options and settings forcontrolling the operation of the database system. This documentprovides an overview of common configurations and examples ofbest-practice configurations for common use cases.

While both interfaces provide access to the same collection of optionsand settings, this document primarily uses the configuration fileinterface. If you run MongoDB using a init script or if you installedfrom a package for your operating system, you likely already have aconfiguration file located at /etc/mongod.conf. Confirm this bychecking the contents of the /etc/init.d/mongod or/etc/rc.d/mongod script to ensure that the init scripts start themongod with the appropriate configuration file.

To start a MongoDB instance using this configuration file, issue acommand in the following form:

  1. mongod --config /etc/mongod.conf
  2. mongod -f /etc/mongod.conf

Modify the values in the /etc/mongod.conf file on your system tocontrol the configuration of your database instance.

Configure the Database

Consider the following basic configuration which uses the YAMLformat:

  1. processManagement:
  2.    fork: true
  3. net:
  4.    bindIp: localhost
  5.    port: 27017
  6. storage:
  7.    dbPath: /srv/mongodb
  8. systemLog:
  9.    destination: file
  10.    path: "/var/log/mongodb/mongod.log"
  11.    logAppend: true
  12. storage:
  13.    journal:
  14.       enabled: true

Or, if using the older .ini configuration file format:

  1. fork = true
  2. bind_ip = localhost
  3. port = 27017
  4. quiet = true
  5. dbpath = /srv/mongodb
  6. logpath = /var/log/mongodb/mongod.log
  7. logappend = true
  8. journal = true

For most standalone servers, this is a sufficient baseconfiguration. It makes several assumptions, but consider thefollowing explanation:

  • fork is true, which enables adaemon mode for mongod, which detaches (i.e. “forks”)the MongoDB from the current session and allows you to run thedatabase as a conventional server.

  • bindIp is localhost, which forces theserver to only listen for requests on the localhost IP. Only bind tosecure interfaces that the application-level systems can access withaccess control provided by system network filtering(i.e. “firewall”).

New in version 2.6: mongod installed from official .deb and .rpm packageshave the bind_ip configuration set to 127.0.0.1 bydefault.

  • port is 27017, which is the defaultMongoDB port for database instances. MongoDB can bind to anyport. You can also filter access based on port using networkfiltering tools.

Note

UNIX-like systems require superuser privileges to attach processesto ports lower than 1024.

  • quiet is true. This disables all butthe most critical entries in output/log file, and is _not_recommended for production systems. If you do set this option, youcan use setParameter to modify this setting duringrun time.

  • dbPath is /srv/mongodb, whichspecifies where MongoDB will store its data files. /srv/mongodband /var/lib/mongodb are popular locations. The user accountthat mongod runs under will need read and write access to thisdirectory.

  • systemLog.path is /var/log/mongodb/mongod.logwhich is where mongod will write its output. If you do not setthis value, mongod writes all output to standard output(e.g. stdout.)

  • logAppend is true, which ensures thatmongod does not overwrite an existing log filefollowing the server start operation.

  • storage.journal.enabled is true, which enablesjournaling. Journaling ensures single instancewrite-durability. 64-bit builds of mongod enablejournaling by default. Thus, this setting may be redundant.

Given the default configuration, some of these values may beredundant. However, in many situations explicitly stating theconfiguration increases overall system intelligibility.

Security Considerations

The following configuration options are useful for limiting access to amongod instance:

  1. net:
  2.    bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
  3. security:
  4.    authorization: enabled
  • net.bindIp

  • This example provides four values to the bindIpoption:

    • localhost, the localhost interface;
    • 10.8.0.10, a private IP address typically used for localnetworks and VPN interfaces;
    • 192.168.4.24, a private network interface typically used forlocal networks; and
    • /tmp/mongod.sock, a Unix domain socket path.Because production MongoDB instances need to be accessible frommultiple database servers, it is important to bind MongoDB tomultiple interfaces that are accessible from your applicationservers. At the same time it’s important to limit these interfacesto interfaces controlled and protected at the network layer.

  • security.authorization

  • Setting this option to true enables the authorizationsystem within MongoDB. If enabled you will need to log in byconnecting over the localhost interface for the first time tocreate user credentials.

See also

Security

Replication and Sharding Configuration

Replication Configuration

Replica set configuration is straightforward, and onlyrequires that the replSetName have a value that is consistentamong all members of the set. Consider the following:

In YAML format

  1. replication:
  2.    replSetName: set0

Or, if using the older configuration file format:

  1. replSet = set0

Use descriptive names for sets. Once configured, use themongo shell to add hosts to the replica set.

See also

Replica set reconfiguration.

To enable authentication for the replica set usingkeyfiles , add the followingkeyFile option [1]:

In YAML format

  1. security:
  2.    keyFile: /srv/mongodb/keyfile

Or, if using the older configuration file format:

  1. keyFile = /srv/mongodb/keyfile

Setting keyFile enables authentication andspecifies a keyfile for the replica set member to use whenauthenticating to each other.

See also

The Replica Set Security section forinformation on configuring authentication with replica sets.

The Replication document for more informationon replication in MongoDB and replica set configuration in general.

[1]Sharded clusters and replica sets can use x.509 for membership verification instead ofkeyfiles. For details, see x.509.

Sharding Configuration

Sharding requires mongod instances with differentmongod configurations for the config servers and the shards. The config servers store the cluster’smetadata, while the shards store the data.

To configure the config server mongod instances, in theconfiguration file, specify configsvr for thesharding.clusterRole setting.

Changed in version 3.4: Starting in version 3.4, MongoDB removes support for mirroredconfig servers and config servers must bedeployed as a replica set.

  1.  sharding:
  2.     clusterRole: configsvr
  3.  net:
  4.     bindIp: 10.8.0.12
  5.     port: 27001
  6. replication:
  7.     replSetName: csRS

To deploy config servers as a replica set, the config servers must runthe WiredTiger Storage Engine. Initiate thereplica set and add members.

To configure the shard mongod instances, specifyshardsvr for the sharding.clusterRole setting, and ifrunning as a replica set, the replica set name:

  1. sharding:
  2.    clusterRole: shardsvr
  3. replication:
  4.    replSetName: shardA

If running as a replica set, initiate theshard replica set and add members.

For the router (i.e. mongos), configure at least onemongos process with the following setting:

  1. sharding:
  2.    configDB: csRS/10.8.0.12:27001

You can specify additional members of the config server replica set byspecifying hostnames and ports in the form of a comma separated listafter the replica set name.

See also

The Sharding section of the manual for moreinformation on sharding and cluster configuration.

Run Multiple Database Instances on the Same System

In many cases running multiple instances of mongod on asingle system is not recommended. On some types of deployments[2] and for testing purposes you may need to run more thanone mongod on a single system.

In these cases, use a base configuration for eachinstance, but consider the following configuration values:

In YAML format:

  1. storage:
  2.    dbPath: /srv/mongodb/db0/
  3. processManagement:
  4.    pidFilePath: /srv/mongodb/db0.pid

Or, if using the older configuration file format:

  1. dbpath = /srv/mongodb/db0/
  2. pidfilepath = /srv/mongodb/db0.pid

The dbPath value controls the location of themongod instance’s data directory. Ensure that each databasehas a distinct and well labeled data directory. ThepidFilePath controls where mongod processplaces it’s process id file. As this tracks the specificmongod file, it is crucial that file be unique and welllabeled to make it easy to start and stop these processes.

Create additional init scripts and/oradjust your existing MongoDB configuration and init script asneeded to control these processes.

[2]Single-tenant systems with SSD or other highperformance disks may provide acceptable performance levels formultiple mongod instances. Additionally, you may find thatmultiple databases with small working sets may function acceptablyon a single system.

Diagnostic Configurations

The following configuration options control various mongodbehaviors for diagnostic purposes:

  • operationProfiling.mode sets the database profiler level. The profiler is not active by defaultbecause of the possible impact on the profiler itself on performance.Unless this setting is on, queries are not profiled.

operationProfiling.slowOpThresholdMs configures thethreshold which determines whether a query is “slow” for thepurpose of the logging system and the profiler. The default value is 100 milliseconds. Setto a lower value if the logging system and the database profiler donot return useful results or set to a higher value to only log thelongest running queries.

Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set nowlog oplog entries that take longer than the slowoperation threshold to apply. These slow oplog messages are loggedfor the secondaries in the diagnostic log under the REPL component with the text appliedop: <oplog entry> took <num>ms. These slow oplog entries dependonly on the slow operation threshold. They do not depend on the loglevels (either at the system or component level), or the profilinglevel, or the slow operation sample rate. The profiler does notcapture slow oplog entries.

  • systemLog.verbosity controls the amount of logging output thatmongod write to the log. Only use this option if you areexperiencing an issue that is not reflected in the normal logginglevel.

Starting in MongoDB 3.0, you can also specify verbosity level forspecific components using thesystemLog.component.<name>.verbosity setting. For the availablecomponents, see component verbosity settings.

For more information, see also Database Profiling andMongoDB Performance.