Run-time Database Configuration

Configure the Database

Consider the following basic configuration:

processManagement:
   fork: true
net:
   bindIp: localhost
   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:

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

• bindIp is localhost, 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").

• port is 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.

  Note

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

• quiet is 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.

• dbPath is /var/lib/mongo, which specifies where MongoDB will store its data files.

  If you installed MongoDB on Linux using a package manager, such as yum or 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 dbPath
  RHEL / CentOS and Amazon	yum	/var/lib/mongo
  SUSE	zypper	/var/lib/mongo
  Ubuntu and Debian	apt	/var/lib/mongodb
  macOS	brew	/usr/local/var/mongodb

  The user account that mongod runs under will need read and write access to this directory.

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

• logAppend is true, which ensures that mongod does not overwrite an existing log file following the server start operation.

• storage.journal.enabled is 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.

Security Considerations

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

net:
   bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
security:
   authorization: enabled

net.bindIp

This example provides four values to the bindIp option:

• localhost, 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.

security.authorization

Setting this option to true enables the authorization system within MongoDB. If enabled you will need to log in by connecting over the localhost interface for the first time to create user credentials.

Replication and Sharding Configuration

replication:
   replSetName: set0

security:
   keyFile: /srv/mongodb/keyfile

 sharding:
    clusterRole: configsvr
 net:
    bindIp: 10.8.0.12
    port: 27001
replication:
    replSetName: csRS

sharding:
   clusterRole: shardsvr
replication:
   replSetName: shardA

sharding:
   configDB: csRS/10.8.0.12:27001

Run Multiple Database Instances on the Same System

In many cases running multiple instances of mongod on a single system is not recommended. On some types of deployments [2] 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 (PID) 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.

Diagnostic Configurations

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.
  
  

  Starting in version 4.2, 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.

  • Are logged under the REPL component with the text applied op: <oplog entry> took <num>ms.

  • Do not depend on the log levels (either at the system or component level)

  • Do not depend on the profiling level.

  • May be affected by slowOpSampleRate, depending on your MongoDB version:

    • In MongoDB 4.2, these slow oplog entries are not affected by the slowOpSampleRate. MongoDB logs all slow oplog entries regardless of the sample rate.

    • In MongoDB 4.4 and later, these slow oplog entries are affected by the slowOpSampleRate.

  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.

For more information, see also Database Profiling and MongoDB Performance.