Why Primary and secondary nodes in MongoDB? - Purpose & Use Cases

The Big Idea

What if your entire business stopped because one computer failed? Primary and secondary nodes save you from that nightmare.

The Scenario

Imagine you run a busy online store. You keep all your sales data on one computer. If that computer crashes, your store stops working and you lose important data.

The Problem

Relying on a single computer is risky. It can break down anytime, causing delays and lost information. Fixing it takes time and can frustrate customers.

The Solution

Primary and secondary nodes work together like a team. The primary handles all the changes, while secondaries keep copies ready. If the primary fails, a secondary quickly takes over, keeping your store running smoothly.

Before vs After

✗ Before

Store data on one server only.

✓ After

Use primary node for writes and secondary nodes for backups and failover.

What It Enables

This setup ensures your data is safe and your service stays online, even if one computer stops working.

Real Life Example

A bank uses primary and secondary nodes to keep customer transactions safe and available 24/7, preventing downtime during server issues.

Key Takeaways

Primary node handles all data changes.

Secondary nodes keep copies for safety and quick recovery.

This system prevents data loss and downtime.

Practice

1. Which statement best describes the role of a primary node in a MongoDB replica set?

easy

A. It acts as a backup and does not participate in replication.

B. It only reads data and never accepts writes.

C. It accepts write operations and replicates data to secondary nodes.

D. It is used only for analytics and reporting.

Solution

1. Step 1: Understand the primary node's function

   The primary node is the main server that accepts all write operations in a replica set.

2. Step 2: Role in replication

   The primary replicates data changes to secondary nodes to keep data consistent.

3. Final Answer:

   It accepts write operations and replicates data to secondary nodes. -> Option C

4. Quick Check:

   Primary node = accepts writes and replicates [OK]

Hint: Primary node handles writes; secondaries replicate [OK]

Common Mistakes:

• Thinking primary only reads data
• Confusing secondary with primary roles
• Assuming primary is just a backup

2. Which of the following is the correct command to check the status of a MongoDB replica set?

easy

A. replica.status()

B. db.replicaStatus()

C. show replicaSet

D. rs.status()

Solution

1. Step 1: Recall MongoDB replica set commands

   The command rs.status() is used to check the status of the replica set.

2. Step 2: Verify other options

   Other options are not valid MongoDB shell commands for replica set status.

3. Final Answer:

   rs.status() -> Option D

4. Quick Check:

   Replica set status command = rs.status() [OK]

Hint: Use rs.status() to check replica set health [OK]

Common Mistakes:

• Using incorrect or non-existent commands
• Confusing database commands with replica set commands
• Typing commands with wrong syntax

3. Given a replica set with one primary and two secondary nodes, what will happen if the primary node goes down?

medium

A. The replica set will stop all read and write operations immediately.

B. One of the secondary nodes will be elected as the new primary.

C. The primary node will automatically restart without intervention.

D. All secondary nodes will become primary nodes simultaneously.

Solution

1. Step 1: Understand replica set failover

   If the primary node fails, the replica set automatically elects a new primary from the secondaries.

2. Step 2: Check other options

   The replica set does not stop all operations; it does not restart primary automatically; multiple primaries cannot exist simultaneously.

3. Final Answer:

   One of the secondary nodes will be elected as the new primary. -> Option B

4. Quick Check:

   Failover elects new primary from secondaries [OK]

Hint: Replica sets auto-elect new primary if current fails [OK]

Common Mistakes:

• Thinking all nodes become primary
• Assuming system stops all operations
• Believing primary restarts automatically

4. You run rs.stepDown() on the primary node but get an error saying "not primary". What is the likely cause?

medium

A. The node is already a secondary, not primary.

B. The command syntax is incorrect.

C. The replica set has only one node.

D. The network connection to the primary is lost.

Solution

1. Step 1: Understand rs.stepDown() usage

   This command only works on a primary node to force it to step down.

2. Step 2: Analyze the error message

   "not primary" means the node is already a secondary, so it cannot step down.

3. Final Answer:

   The node is already a secondary, not primary. -> Option A

4. Quick Check:

   rs.stepDown() error "not primary" = node is secondary [OK]

Hint: rs.stepDown() only works on primary nodes [OK]

Common Mistakes:

• Trying to step down a secondary node
• Assuming syntax error causes this message
• Ignoring the node's current role

5. You want to configure a MongoDB replica set with one primary and two secondaries. Which of the following configurations ensures data safety and availability during a primary failure?

hard

A. Set all nodes with priority 1 and enable majority write concern.

B. Set one secondary with priority 0 and disable write concern.

C. Use only one node as primary without secondaries.

D. Set all nodes with priority 0 to prevent elections.

Solution

1. Step 1: Understand priority and write concern

   Setting all nodes with priority 1 allows any secondary to become primary if needed. Majority write concern ensures writes are acknowledged by most nodes.

2. Step 2: Evaluate other options

   Priority 0 disables election for that node; disabling write concern risks data loss; single node has no failover; priority 0 on all nodes prevents elections.

3. Final Answer:

   Set all nodes with priority 1 and enable majority write concern. -> Option A

4. Quick Check:

   Priority 1 + majority write concern = safe failover [OK]

Hint: Use priority 1 and majority write concern for safety [OK]

Common Mistakes:

• Disabling write concern risking data loss
• Setting priority 0 disables elections
• Using single node without replicas