Primary and secondary nodes in MongoDB - Time & Space Complexity
When working with MongoDB replica sets, operations can run on primary or secondary nodes.
We want to understand how the time to complete operations changes depending on which node handles them.
Analyze the time complexity of a read operation on primary vs secondary nodes.
// Read from primary node
const primaryResult = db.collection.find({}).toArray();
// Read from secondary node with read preference
const secondaryResult = db.getMongo().setReadPref('secondary').getDB('test').collection.find({}).toArray();
This code reads all documents from a collection, once from the primary and once from a secondary node.
Look for repeated work done during the read operation.
- Primary operation: Scanning all documents in the collection to return results.
- How many times: Once per read operation, scanning each document once.
As the number of documents grows, the time to read all documents grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 document reads |
| 100 | 100 document reads |
| 1000 | 1000 document reads |
Pattern observation: The time grows roughly in direct proportion to the number of documents.
Time Complexity: O(n)
This means the time to read all documents grows linearly with the number of documents.
[X] Wrong: "Reading from a secondary node is always faster than from the primary node."
[OK] Correct: Both nodes scan the same number of documents, so time depends mostly on data size, not node type. Network and replication lag can affect speed but do not change the fundamental time complexity.
Understanding how operations scale on primary and secondary nodes helps you design efficient database queries and explain trade-offs clearly in interviews.
"What if we added an index to the collection? How would the time complexity of reading documents change on primary and secondary nodes?"
Practice
primary node in a MongoDB replica set?Solution
Step 1: Understand the primary node's function
The primary node is the main server that accepts all write operations in a replica set.Step 2: Role in replication
The primary replicates data changes to secondary nodes to keep data consistent.Final Answer:
It accepts write operations and replicates data to secondary nodes. -> Option CQuick Check:
Primary node = accepts writes and replicates [OK]
- Thinking primary only reads data
- Confusing secondary with primary roles
- Assuming primary is just a backup
Solution
Step 1: Recall MongoDB replica set commands
The commandrs.status()is used to check the status of the replica set.Step 2: Verify other options
Other options are not valid MongoDB shell commands for replica set status.Final Answer:
rs.status() -> Option DQuick Check:
Replica set status command = rs.status() [OK]
- Using incorrect or non-existent commands
- Confusing database commands with replica set commands
- Typing commands with wrong syntax
Solution
Step 1: Understand replica set failover
If the primary node fails, the replica set automatically elects a new primary from the secondaries.Step 2: Check other options
The replica set does not stop all operations; it does not restart primary automatically; multiple primaries cannot exist simultaneously.Final Answer:
One of the secondary nodes will be elected as the new primary. -> Option BQuick Check:
Failover elects new primary from secondaries [OK]
- Thinking all nodes become primary
- Assuming system stops all operations
- Believing primary restarts automatically
rs.stepDown() on the primary node but get an error saying "not primary". What is the likely cause?Solution
Step 1: Understand rs.stepDown() usage
This command only works on a primary node to force it to step down.Step 2: Analyze the error message
"not primary" means the node is already a secondary, so it cannot step down.Final Answer:
The node is already a secondary, not primary. -> Option AQuick Check:
rs.stepDown() error "not primary" = node is secondary [OK]
- Trying to step down a secondary node
- Assuming syntax error causes this message
- Ignoring the node's current role
Solution
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.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.Final Answer:
Set all nodes with priority 1 and enable majority write concern. -> Option AQuick Check:
Priority 1 + majority write concern = safe failover [OK]
- Disabling write concern risking data loss
- Setting priority 0 disables elections
- Using single node without replicas
Ready to prove it?
Pass the test and this pattern moves unknown
