Replica Sets & Elections

Replica Sets & Elections

A Replica Set is a group of mongod instances that maintain the same data set. Replication provides redundancy and high availability, ensuring that your application remains online even if a server fails.

🏗️ 1. Replica Set Architecture

Replica Sets follow a Single-Primary model, where only one node can accept write operations at any given time.

• Primary: The only node that receives all write operations. All writes are recorded in the Primary’s Oplog.
• Secondaries: Nodes that replicate the Primary’s Oplog and apply the operations to their own data sets.
• Arbiter: A node that does not store data but participates in elections to break ties.

Avoid Arbiters in Production

While Arbiters are useful for maintaining an odd number of voting nodes, they do not provide data redundancy. Always prefer adding a full Secondary node when possible.

---

🚀 2. The Election Algorithm (PV1)

MongoDB uses a consensus protocol similar to Raft to handle elections and automatic failover.

Election Triggers

An election occurs when:

1. A new Replica Set is initialized.
2. The Primary becomes unreachable (e.g., heartbeat failure).
3. A Secondary with higher priority becomes available.

How Elections Work

1. Heartbeats: All nodes send heartbeats to each other every 2 seconds.
2. Nomination: If a Primary doesn’t respond for 10 seconds, a Secondary will nominate itself for election.
3. Voting: Other nodes vote based on data freshness (oplog position) and connectivity.
4. Outcome: A node must receive a majority of voting members to become Primary.

---

⚡ 3. Read Preferences & Consistency

While all writes go to the Primary, you can scale read operations by reading from Secondaries.

Preference	Description
primary	(Default) Always read from the Primary.
secondary	Always read from a Secondary.
nearest	Read from the node with the lowest network latency.

Pymongo Example: Setting Read Preference

from pymongo import MongoClient
from pymongo.read_preferences import ReadPreference

# Connect with secondary read preference
client = MongoClient(
    'mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaSet=myReplicaSet',
    read_preference=ReadPreference.SECONDARY_PREFERRED
)

db = client['analytics']
# This query will prefer reading from a secondary node
docs = db.logs.find({"severity": "ERROR"})

---

🛡️ 4. Write Concern

Write Concern describes the level of acknowledgement requested from MongoDB for write operations.

• w: 1: Only wait for acknowledgement from the Primary.
• w: “majority”: Wait for a majority of voting nodes to acknowledge the write. This is the safest setting and prevents rollbacks in the event of a failover.
• j: true: Wait until the operation is written to the on-disk journal.

Mongo Shell Example: Majority Write Concern

db.users.insertOne(
  { name: "John Doe", email: "john@example.com" },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
);

---

💡 Best Practices

1. Always use an odd number of members: To ensure a clear majority during elections (e.g., 3, 5, or 7 nodes).
2. Deploy across regions: Distribute nodes across different availability zones or data centers for true disaster recovery.
3. Monitor Replication Lag: Use rs.printReplicationInfo() or rs.printSecondaryReplicationInfo() to ensure Secondaries are staying up to date with the Primary.