google-templatesmongodb

Understand the default MongoDB cluster configuration

The Bitnami Multi-Tier Solution for MongoDB uses multiple VMs. One node in the cluster is designated as the primary node and receives all write operations, while other nodes are designated as secondary nodes and asynchronously replicate the operations performed by the primary node on their own copies of the data set. Binary logging is enabled by default.

If a primary node fails, an election takes place and the first secondary node receiving a majority of votes becomes the new primary node. This configuration provides a horizontally scalable and fault-tolerant deployment.

If you select an even number of nodes, it’s a good idea to add an arbiter node. Arbiter nodes do not store any data; their function is to provide an additional vote in replica set elections.

The minimum requirement for a MongoDB cluster is to have at least two nodes: one primary and one secondary node. A replica set can have up to 50 nodes, but only 7 can be voting members. Learn more about MongoDB Replica Set Elections.

To understand how it works, consider the example below of a three-node cluster/ replica set (one primary, one secondary and one arbiter):

  • On the primary node, see the databases you have:

    replicaset:PRIMARY> show dbs
    admin    0.000GB
    local    0.000GB
    bitnamidb  0.000GB
    replicaset:PRIMARY>
    
  • Create a database and add a collection in the primary node:

    replicaset:PRIMARY> use bitnamidb
    switched to db bitnamidb
    replicaset:PRIMARY> db.createCollection('bitnamicol')
    { "ok" : 1 }
    
  • Check the databases on your secondary node. Reading or running commands in a non-primary node is disabled by default:

    replicaset:SECONDARY> show dbs
    2016-12-22T10:23:28.789+0000 E QUERY    [main] Error:
    listDatabases failed:{
    "ok" : 0,
    "errmsg" : "not master and slaveOk=false",
    "code" : 13435,
    "codeName" : "NotMasterNoSlaveOk"
    } :
    _getErrorWithCode@src/mongo/shell/utils.js:25:13
    Mongo.prototype.getDBs@src/mongo/shell/mongo.js:62:1
    shellHelper.show@src/mongo/shell/utils.js:755:19
    shellHelper@src/mongo/shell/utils.js:645:15
    @(shellhelp2):1:1
    
  • You can allow users to run commands in the secondary or arbiter nodes by running this command:

    replicaset:SECONDARY> rs.slaveOk()
    replicaset:SECONDARY> show dbs
    admin    0.000GB
    local    0.000GB
    bitnamidb  0.000GB
    replicaset:SECONDARY>
    

    This shows that the databases added on the primary node have been replicated to the secondary node(s). You can also modify the read preferences when running any command.

  • Check the databases on the arbiter node. It is not allowed to replicate data or accept write operations:

    replicaset:ARBITER> show dbs
    2016-12-22T10:26:04.186+0000 E QUERY    [main] Error: listDatabases failed:{
    "ok" : 0,
    "errmsg" : "not master and slaveOk=false",
    "code" : 13435,
    "codeName" : "NotMasterNoSlaveOk"
    } :
    _getErrorWithCode@src/mongo/shell/utils.js:25:13
    Mongo.prototype.getDBs@src/mongo/shell/mongo.js:62:1
    shellHelper.show@src/mongo/shell/utils.js:755:19
    shellHelper@src/mongo/shell/utils.js:645:15
    @(shellhelp2):1:1
    replicaset:ARBITER> rs.slaveOk()
    replicaset:ARBITER> show dbs
    admin  0.000GB
    local  0.000GB
    replicaset:ARBITER>
    

For more information, refer to the MongoDB documentation on replication.

Last modification September 19, 2018