What kind of replication happens in Mongo DB?

It has Master-Slave replication. 

Each Primary node has multiple replica sets that update themselves asynchronously using the operation log file of their respective primary node.  

What are different data synchronizations present in MongoDB?

How replica set discovers that primary node is down? 

Using Heartbeats:

• Replica set members send heartbeats (pings) to each other every two seconds.
• If a heartbeat does not return within 10 seconds, the other members mark the delinquent member as inaccessible.

What if Primary node becomes in-accessible?

• One of the secondary nodes needs to become the primary node. 
• Till a new primary is elected among the secondary nodes, the system remains unavailable to the user to make any new write query. 

What is an arbiter? 

Sometimes you may have just 2 nodes to carry data, let’s say because of cost constraints. In such cases, you can add an arbiter to your replica set. 

Can you tell me more about Replica Set Elections?

Replica sets use elections to determine which set member will become primary.

Replica sets can trigger an election in response to a variety of events, such as:

• Adding a new node to the replica set
• Initiating a replica set
• Performing replica set maintenance using methods such as rs.stepDown() or rs.reconfig(), and
• The secondary members losing connectivity to the primary for more than the configured timeout (10 seconds by default).

Can we give priority to secondary nodes to tell which one to select on priority if primary is down? 

After a replica set has a stable primary, the election algorithm will make a “best-effort” attempt to have the secondary with the highest priority available call an election.

Member priority affects both the timing and the outcome of elections; secondaries with higher priority call elections relatively sooner than secondaries with lower priority, and are also more likely to win. However, a lower priority instance can be elected as primary for brief periods, even if a higher priority secondary is available. Replica set members continue to call elections until the highest priority member available becomes primary.

Members with a priority value of 0 cannot become primary and do not seek election.

What happens in case of Network Partition? 

A network partition may segregate a primary into a partition with a minority of nodes. When the primary detects that it can only see a minority of nodes in the replica set, the primary steps down as primary and becomes a secondary. Independently, a member in the partition that can communicate with a majority of the nodes (including itself) holds an election to become the new primary.

Who all can vote in case required? 

The replica set member configuration setting members[n].votes and member state determine whether a member votes in an election.

• All replica set members that have their members[n].votes setting equal to 1 vote in elections. To exclude a member from voting in an election, change the value of the member’s members[n].votes configuration to 0.
• Only voting members in the following states are eligible to vote:
  • PRIMARY
  • SECONDARY
  • STARTUP2
  • RECOVERING
  • ARBITER
  • ROLLBACK

What is the use of Non-Voting Members? 

Although non-voting members do not vote in elections, these members hold copies of the replica set’s data and can accept read operations from client applications.

Because a replica set can have up to 50 members, but only 7 voting members, non-voting members allow a replica set to have more than seven members.

Non-voting (i.e. votes is 0) members must have priority of 0.

[private]

[/private]

Can a client read from secondary nodes in MongoDB? 

Yes. We can configure MongoDB to allow read from secondary nodes.

Will we get latest data from secondary nodes if I allow read from secondary nodes? 

This depends on read preference modes you have setup. Modes other than primary may return stale data because with asynchronous replication, data in the secondary may not reflect the most recent write operations.

What are different read preference modes in MongoDB?

Read Preference Mode	Description
primary	Default mode. All operations read from the current replica set primary.
primaryPreferred	In most situations, operations read from the primarybut if it is  unavailable, operations read from secondarymembers.
secondary	All operations read from the secondarymembers of the replica set.
secondaryPreferred	In most situations, operations read from secondarymembers but  if no secondarymembers are available, operations read from the primary.
nearest	Operations read from member of the replica setwith the least network latency,   irrespective of the member’s type.

Is it possible for client to read results of write before they are acknowledged? 

Yes. Clients can see the results of writes before they are acknowledged or have propagated to a majority of replica set members:

• Clients using “local” (i.e. the default) readConcern can see the result of a write operation before the write operation is acknowledged to the issuing client.
• Clients using “local” (i.e. the default) readConcern can read data which may be subsequently rolled back.

What are different Read Concern Levels? 

The following read concern levels are available:

level	Description
local	Default. The query returns data from the instance with no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back).
majority	The query returns data that has been acknowledged by a majority of the replica set members.
linearizable	The query returns data that reflects all successful majority-acknowledged writes that completed prior to the start of the read operation. The query may wait for concurrently executing writes to propagate to a majority of replica set members before returning results.