7/25/2019 Mongo Notes

1/3

Up but not online

Now initiate the set.---Specify the config for the set---specify any initial data (the others will have to start from clean slate andsync slowly)send initiate command to server that has the initial datareplSetInitiaters.initiate()

Do not use local host as much as possible because all members have to be on thelocalhost

Better to use logical names for the set names, but definitely not ip address (not good practice). DNS is still ok to use andhave a name/etc/hosts --complexIf you use DNS, use appropriate Time To Live (TTL)

If one DNS is down, and you put a new DNS to copy, TTL will be important

TTL for few minutes is optimal (subjective to company) ~ 5 minutes

oplogs are getting created.

Shell shows the state: we are the primarySet name is abc

Lets check the rest

mystate means primaryoptime: How update is this server?optimeDate: Time of the last operation

rs.status() is from the Primary's point of view in this case.

Shifted to system local db.

abc:PRIMARY> rs.conffunction () { return db.getSisterDB("local").system.replset.findOne(); }abc:PRIMARY> dbtestabc:PRIMARY> use localswitched to db localabc:PRIMARY> show collectionsmeoplog.rsslavesstartup_logsystem.indexessystem.replset

abc:PRIMARY> db.system.replset.find(){ "_id" : "abc", "version" : 1, "members" : [ { "_id" : 0, "host" : "precise64:27001" }, { "_id" : 1, "host" : "precise64:27002" }, { "_id" : 2, "host" : "precise64:27003" } ] }

We are storing the config in a local db in a collection called system.replset.

It has only 1 document ever at most.

Config of replset is a single doc.

7/25/2019 Mongo Notes

2/3

Schema design: we did not put one doc per replica set because having in one dochelpsto modify atomically

To change use reconfig

Lag is few millisecs at the most to secondary for a writeBy default, no reads from secondary

If you want to be ok with it even if something is wrong with cluster, say slaveOk()

abc:PRIMARY> for ( var i = 0; i < 50000 ; i++ ) { db.foo.insert ( { _id : i } ); sleep(1); }

You can check the lag here

Sleep is for 1milli sec so it is not too fast.

Lets do failover

Kill Primary--> its a clean shutdown

Never use -9 (hard forceful shutdown) to test crash recovery

Use normal kill--Always

The primary is killed andThe secondary now becomes the primary for 27002Process is gone for earlier Primary for 27001

Failover has occured. 27003 is still secondary and syncing from 27002

Connected to 27003 which still has the data

Go back to primary

Let's now restart the node that is down.Check if the data that was written when 27001 was down is still there.

7/25/2019 Mongo Notes

3/3