- Administration >
- Run-time Database Configuration
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 run MongoDB using a control script or installed from
a package for your operating system, you likely already have a
configuration file located at /etc/mongodb.conf
. Confirm this by
checking the content of the /etc/init.d/mongod
or
/etc/rc.d/mongod
script to insure that the control scripts start the mongod
with the appropriate
configuration file (see below.)
To start MongoDB instance using this configuration issue a command in the following form:
Modify the values in the /etc/mongodb.conf
file on your system to
control the configuration of your database instance.
Starting, Stopping, and Running the Database¶
Consider the following basic configuration:
For most standalone servers, this is a sufficient base configuration. It makes several assumptions, but consider the following explanation:
fork
istrue
, which enables a daemon mode formongod
, which detaches (i.e. “forks”) the MongoDB from the current session and allows you to run the database as a conventional server.bind_ip
is127.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”).port
is27017
, 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
istrue
. This disables all but the most critical entries in output/log file. In normal operation this is the preferable operation to avoid log noise. In diagnostic or testing situations, set this value tofalse
. UsesetParameter
to modify this setting during run time.dbpath
is/srv/mongodb
, which specifies where MongoDB will store its data files./srv/mongodb
and/var/lib/mongodb
are popular locations. The user account thatmongod
runs under will need read and write access to this directory.logpath
is/var/log/mongodb/mongod.log
which is wheremongod
will write its output. If you do not set this value,mongod
writes all output to standard output (e.g.stdout
.)logappend
istrue
, which ensures thatmongod
does not overwrite an existing log file following the server start operation.journal
istrue
, which enables journaling. Journaling ensures single instance write-durability. 64-bit builds ofmongod
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 collection of configuration options are useful for
limiting access to a mongod
instance. Consider the
following:
Consider the following explanation for these configuration decisions:
“
bind_ip
” has three values:127.0.0.1
, the localhost interface;10.8.0.10
, a private IP address typically used for local networks and VPN interfaces; and192.168.4.24
, a private network interface typically used for local networks.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.
“
nounixsocket
” totrue
disables the UNIX Socket, which is otherwise enabled by default. This limits access on the local system. This is desirable when running MongoDB on systems with shared access, but in most situations has minimal impact.“
auth
” istrue
enables the authentication system within MongoDB. If enabled you will need to log in by connecting over thelocalhost
interface for the first time to create user credentials.
See also
Replication and Sharding Configuration¶
Replication Configuration¶
Replica set configuration is straightforward, and only
requires that the replSet
have a value that is consistent
among all members of the set. Consider the following:
Use descriptive names for sets. Once configured use the
mongo
shell to add hosts to the replica set.
See also
To enable authentication for the replica set, add the following option:
New in version 1.8: for replica sets, and 1.9.1 for sharded replica sets.
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.
See also
The “Replica set Reconfiguration” section for information regarding the process for changing replica set during operation.
Additionally, consider the “Replica Set Security” section for information on configuring authentication with replica sets.
Finally, see the “Replication” index and the “Replica Set Fundamental Concepts” document for more information on replication in MongoDB and replica set configuration in general.
Sharding Configuration¶
Sharding requires a number of mongod
instances with
different configurations. The config servers store the cluster’s
metadata, while the cluster distributes data among one or more shard
servers.
Note
Config servers are not replica sets.
To set up one or three “config server” instances as normal mongod
instances, and then add the following
configuration option:
This creates a config server running on the private IP address
10.8.0.12
on port 27001
. Make sure that there are no port
conflicts, and that your config server is accessible from all of your
“mongos
” and “mongod
” instances.
To set up shards, configure two or more mongod
instance
using your base configuration, adding the
shardsvr
setting:
Finally, to establish the cluster, configure at least one
mongos
process with the following settings:
You can specify multiple configdb
instances by
specifying hostnames and ports in the form of a comma separated
list. In general, avoid modifying the chunkSize
from
the default value of 64, [1] and should ensure this setting is consistent
among all mongos
instances.
[1] | Chunk size is 64 megabytes by default, which provides the ideal balance between the most even distribution of data, for which smaller chunk sizes are best, and minimizing chunk migration, for which larger chunk sizes are optimal. |
See also
The “Sharding” section of the manual for more information on sharding and cluster configuration.
Running 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:
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 control scripts and/or adjust your existing MongoDB configuration and control script as needed to control these processes.
[2] | 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. |
Diagnostic Configurations¶
The following configuration options control various mongod
behaviors for diagnostic purposes. The following settings have default
values that tuned for general production purposes:
Use the base configuration and add these options if you are experiencing some unknown issue or performance problem as needed:
slowms
configures the threshold for the database profiler to consider a query “slow.” The default value is 100 milliseconds. Set a lower value if the database profiler does not return useful results. See Optimization Strategies for MongoDB Applications for more information on optimizing operations in MongoDB.profile
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 has a value, queries are not profiled.verbose
enables a verbose logging mode that modifiesmongod
output and increases logging to include a greater number of events. Only use this option if you are experiencing an issue that is not reflected in the normal logging level. If you require additional verbosity, consider the following options:Each additional level
v
adds additional verbosity to the logging. Theverbose
option is equal tov = true
.diaglog
enables diagnostic logging. Level3
logs all read and write options.objcheck
forcesmongod
to validate all requests from clients upon receipt. Use this option to ensure that invalid requests are not causing errors, particularly when running a database with untrusted clients. This option may affect database performance.cpu
forcesmongod
to report the percentage of the last interval spent in write-lock. The interval is typically 4 seconds, and each output line in the log includes both the actual interval since the last report and the percentage of time spent in write lock.