Day06 as #100DaysofMongoDB as #100daysofcode
Extending the understanding of Replication, will be discussion few interesting insights from Write Concern in replica set.
In simple words, write concern determines the type of acknowledgement received for write operation to a standalone mongod, replica sets and sharded clusters. The Primary node of the replica set keeps a track of how well the secondaries are in sync with the oplog when compared to primary.
A write concern can specify a number of nodes to wait for, or majority .
If a write operation does not have a write concern, the default configuration is chosen. This default configuration is either cluster-wide write concern or implicit default write concern.
The cluster wide is set using setDefaultRWConcern command. and when this is not set, the default will be set and this default write concern is known as implicit default write concern. Mostly it is {w: majority}.
The calculation for the default write concern is given by:
if ((#arbiters > 0) AND (#non-arbiters <= majority(#voting nodes)) then {w:1} else {w:majority}
The rule stand out to be an exception in case of sharded clusters where the write concern will always be a majority.
The Oplog maintenance:
The secondary nodes keeps itself in sync with their sync source. This is done via OplogFetcher… This OplogFetcher maintains a buffer known as OplogBuffer. A separate thread, runs an OplogBatcher which pulls from the buffer to the fetcher and creates a new batch to be applied.
Will be posting some new understanding about Replication and Topology Coordinators… Stay Tuned.
Regards
Aasawari