Day05 of 100DaysOfMongoDB as 100daysofcode
As we know that Replication in MongoDB is asynchronous hence follows a master-slave replication approach.
This means the reads from secondary may return data that doesn’t reflect the state of data on the primary
The complete basis of replication depends on the oplog which is collection that keeps a record of all the operations on the Primary dataset.
In the latest version of MongoDB oplog, the entry is deleted only when the oplog has reached specified size or entry is older than configures amount of time.
The Primary node of the replica set maintains an oplog which is then copied by the secondary nodes’ oplog and this proves to be advantageous to recover when the Primary nodes steps down and initiates an election. The secondary node with the most recent data will be elected as the primary for the replica set.
Consider a failover condition when the Primary node goes does and an election is initiated. Discussion a few factors and conditions which effect the election process.
- The protocol Version:
- Heartbeats: The continuous polling between replica et members to verify the state of the members.
- The priority: Each of the members of the replica sets are provided with a priority which marks as a factor on selection of the next primary.
However, the priority of the member is neglected when it comes to the member having recent writes. - Mirrored Reads: However, the priority of the member is neglected when it comes to the member having the most recent accessed data.
If you have any questions with reference to the replica sets or architecture please feel free to reply below.
Thanks
Aasawari
Share on twitter: https://twitter.com/Aasawari_24