Sample YAML Configuration Files for MongoDB?

Question

The MongoDB configuration options documentation lists all the available options that can be specified, but does anyone have a set of fully formed example YAML formatted config files for MongoDB instances in various roles?

A set of examples for the common roles would be a very useful starting point for those starting from scratch, or looking to test with the latest configuration file format.

Answer 1

Here are several examples of YAML configs for Linux (Windows paths and options are a little different), essentially explicitly setting some defaults and commonly used settings.

First, a standalone mongod with the default port, path, journal settings - this would be the type of configuration used for local testing, with a few extras so show the general style:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/data/db/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 127.0.0.1
    port: 27017
    wireObjectCheck : false
    unixDomainSocket: 
        enabled : true

Some notes on this config:

• You generally don't want to have the object check off (wireObjectCheck: false) in production, but for a bulk load of data for testing purposes, it will speed things up a little and is a minimal risk in such an environment
• This would not work for replication unless all member of the replica set were on the loopback IP address (as this is the only binding specified), so beware

Now, let's look at a sample config file for a typical production replica set member with authentication enabled and running as part of a sharded cluster:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: 192.0.2.1
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

Some notes on this configuration:

• Again there are explicit declarations of defaults and implied settings (port is implied by clusterRole for example), generally this is recommended to avoid confusion
• The IP binding is now the external IP address only, so communication on the loopback IP will now fail, but replication can work to remote hosts
• The oplog defaults to 5% of free space, so it is common on large volumes to be more conservative and explicitly set the size allocated

Next up, a sample mongos config:

sharding:
    configDB: "config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
    autoSplit: true
systemLog:
    destination: file
    path: "/var/log/mongos.log"
processManagement:
    fork: true
net:
    port: 27017
    bindIp: 192.0.2.2
    maxIncomingConnections: 5000
security:
    keyFile: "/data/key/mongos.key"
    authorization: "enabled"

The only required changes here are removals that don't apply to the mongos (since it does not store data) and the addition of the configDB string, which must be identical on all mongos processes. I added the maximum connections setting as an example, it's not required but can often be a good idea for larger clusters.

Rounding out the sharded cluster we have a sample config server, which is really a subset of the replica set member with some minor changes:

storage:
    dbPath: "/data/db"
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 192.0.2.3
    port: 27019
security:
    keyFile: "/data/key/config.key"
    authorization: "enabled"
sharding:
    clusterRole: "configsvr"

Finally, MongoDB 3.0 (not yet released at the time of writing this) will introduce several new options, especially with the introduction of the new storage engines. Therefore, here is an example of how to configure the same replica set member, but this time with the WiredTiger storage engine and (the default) snappy compression method (note: altered from original because of SERVER-16266, and added sample engineConfig):

storage:
    dbPath: "/data/db"
    engine: "wiredTiger"
    wiredTiger:
        engineConfig: 
            cacheSizeGB: 8
        collectionConfig: 
            blockCompressor: snappy        
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: "192.0.2.1,127.0.0.1"
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

As a final bonus addition, I showed how to bind multiple IP addresses using a list, in this case an external IP and the loopback IP.