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 recipe Starting multiple instances as part of a replica set from Chapter 1, Installing and Starting the Server for the prerequisites and know about the 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 connect randomly to any one member; use
rs.status()and then determine the primary. - With shell open, first switch to
localdatabase and the 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 one document and it contains the hostname of the server to which we are currently connected to:>db.me.findOne() - There would be two fields, the hostname and the
_idfield. Take a note of the_idfield—it is important. - Take a look at the
replset.minvalidcollection. You will have to connect to a secondary member from the shell to execute the following query. Switch to thelocaldatabase first:> use local switched to db local > db.replset.minvalid.find()
- This collection just contains the single document with a key
tsand a value that is the timestamp till the time the secondary we are connected to is synchronized. Note down this time. - From the shell in primary, insert a document in any collection. We will use the database as test. Execute the following 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 should see that the time against the field
tshas now incremented corresponding to the time 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 collection
system.replset. This collection is the place where the replica set configuration is stored. Execute the following:> db.system.replset.find().pretty() - Actually, when we execute
rs.conf(), the following query gets executed:db.getSisterDB("local").system.replset.findOne()
The database local is a special (non-replicated) database that is used to hold the replication and instance specific details in it. Try creating a collection of your own in the local database and insert some data in it; it would not be replicated to the secondary nodes.
This database gives us some 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 it.
Most the collections are pretty straightforward. From the shell of the secondary execute the query db.me.findOne() in the local database and we should see that _id 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 till what time the secondary instances are synced up with the primary. We saw the collection replset.minvalid on the secondary, which tells us the time till which it is synced with primary. This value in the syncedTo time on primary would be same as in replset.minvalid on respective secondary.