In this recipe, we will explore the local database from a replica set's perspective. The local database may contain collections that are not specific to replica sets, but we will focus only on the replica-set-specific collections and try to take a look at what's in them and what they mean.
Refer to the Starting multiple instances as part of a replica set recipe in Chapter 1, Installing and Starting the MongoDB Server, for the prerequisites and to know about replica set basics. Go ahead and set up a simple three-node replica set on your computer, as mentioned in the recipe.
- With the replica set up and running, we need to open a shell connected to the primary. You may randomly connect to any one member, execute
rs.status(), and then determine the primary. - With the shell opened, first switch to the
localdatabase and then view the collections in thelocaldatabase as follows:> use local switched to db local > show collections
- You should find a collection called
me. Querying this collection should show us a document that contains the hostname of the server to which we are currently connected:> db.me.findOne()There will be two fields,
hostnameand_id. Take note of the_idfield; it is important. - We will now query the
slavescollection as follows:> db.slaves.find().pretty() - Take a note of the fields present in these documents.
- The next collection to look at is
replset.minvalid. You will have to connect to a secondary member from the shell to execute the following query. Switch to thelocaldatabase first as follows:> use local switched to db local > db.replset.minvalid.find()
This collection just contains a single document with a key
tsand a value, which is the timestamp for the time the secondary we are connected to is synchronized. Note down this time. - From the shell in the primary, insert a document in any collection. We will use the database
test. Execute the following commands from the shell of the primary member:> use test switched to db test > db.replTest.insert({i:1})
- Query the secondary again as follows:
> db.replset.minvalid.find()We see that the time against the
tsfield has now incremented corresponding to the time at which this replication happened from primary to secondary. With a slave delayed node, you will see this time getting updated only after the delay period has elapsed. - Finally, we will see the
system.replsetcollection. This collection is where the replica set configuration is stored. Execute the following command:> db.system.replset.find().pretty()Actually, when we execute
rs.conf(), the following query gets executed:> db.getSisterDB("local").system.replset.findOne()
The local database is a special database that is used to hold the replication and instance-specific details in it. This is a nonreplicated database. Try creating a collection of your own in the local database and insert some data in it; it will not be replicated to the secondary nodes.
This database gives us a view of the data stored by Mongo for internal use. However, as an administrator, it is good to know about these collections and the type of data in them.
Most of the collections are pretty straightforward. We will take a closer look at the slaves collection. Let's take a look at the following example:
{ "_id" : ObjectId("52f138169da4944dff694e26"), "config" : { "_id" : 1, "host" : "Amol-PC:27001" }, "ns" : "local.oplog.rs", "syncedTo" : Timestamp(1391928970, 1) }
This collection contains the document for all the secondary members that have synched from it. The _id field here is not a randomly chosen ID, but has the same value as the _id field of the document in the me collection of the respective secondary member nodes. From the shell of the secondary, execute the db.me.findOne() query in the local database and we should see that the _id field there should match the _id field of the document present in the slaves collection.
The config document we see gives the hostname of the secondary instance that we are referring to. Note that the port and other configuration options of the replica set member are not present in this document. Finally, the syncedTo time tells us what time are secondary instances are synced up to with the primary. We saw the replset.minvalid collection on the secondary, which tells the time to which it is synced with the primary. This value in syncedTo in the primary will be the same as in replset.minvalid in the respective secondary.