Read concern levels (local, majority, snapshot) in MongoDB - Step-by-Step Execution

Concept Flow - Read concern levels (local, majority, snapshot)

Client sends read request

↓

Check read concern level

↓

local

↓

Return data to client

The client sends a read request with a specified read concern level. Depending on the level (local, majority, snapshot), MongoDB applies different consistency guarantees before returning the data.

Execution Sample

MongoDB

db.collection.find().readConcern('majority')

Returns data that has been acknowledged by a majority of replica set nodes.

Execution Table

Step	Read Concern Level	Data Source	Consistency Guarantee	Result
1	local	Primary or secondary node	Reads the most recent data on the node, may not be majority committed	Returns latest local data, may be stale
2	majority	Primary or secondary node	Reads data acknowledged by majority of nodes	Returns data confirmed by most nodes
3	snapshot	Consistent snapshot at a point in time	Reads data as it existed at a specific cluster time	Returns data consistent across collections at snapshot time
4	exit	-	-	Read operation completes and returns data

💡 Read operation finishes after returning data according to the specified read concern level

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
readConcern	undefined	local	majority	snapshot	snapshot
dataSource	none	local node	replica set node	snapshot view	snapshot view
dataReturned	none	local data	majority confirmed data	snapshot consistent data	snapshot consistent data

Key Moments - 3 Insights

Why does 'local' read concern sometimes return stale data?

Because 'local' reads from a single node without waiting for majority confirmation, it may return data that is not yet replicated to other nodes, as shown in execution_table row 1.

How does 'majority' read concern ensure stronger consistency?

'majority' waits for data to be acknowledged by most replica set nodes before reading, ensuring the data is durable and consistent, as shown in execution_table row 2.

What makes 'snapshot' read concern different from 'majority'?

'snapshot' provides a point-in-time consistent view across multiple collections, not just majority-acknowledged data, as shown in execution_table row 3.

Visual Quiz - 3 Questions

Look at the execution_table, which read concern level reads data from a consistent snapshot at a point in time?

A snapshot

B local

C majority

D none

💡 Hint

Check execution_table row 3 under 'Read Concern Level' and 'Data Source'

At which step does the read concern guarantee data is acknowledged by most nodes?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at execution_table row 2 for 'Consistency Guarantee'

If you want the freshest data without waiting for replication, which read concern would you choose?

A majority

B snapshot

C local

D linearizable

💡 Hint

Refer to execution_table row 1 for 'Read Concern Level' and 'Result'

Concept Snapshot

Read concern levels control data consistency in MongoDB reads.
local: reads from a single node, may be stale.
majority: reads data confirmed by most nodes.
snapshot: reads a consistent point-in-time view.
Choose based on your consistency and latency needs.

Full Transcript

This visual execution trace shows how MongoDB handles read requests with different read concern levels: local, majority, and snapshot. The client sends a read request specifying the read concern. For local, MongoDB reads from a single node and returns the latest data on that node, which might be stale if not replicated. For majority, it reads data acknowledged by most replica set nodes, ensuring stronger consistency. Snapshot reads provide a consistent view of data at a specific point in time across collections. The execution table details each step, data source, and consistency guarantee. Variable tracking shows how readConcern, dataSource, and dataReturned change through the steps. Key moments clarify common confusions about staleness and consistency. The quiz tests understanding of which read concern provides which guarantees. The snapshot summarizes the key points for quick reference.

Practice

1. Which MongoDB read concern level provides the fastest read but may return data that is not yet acknowledged by majority of nodes?

easy

A. local

B. majority

C. snapshot

D. linearizable

Solution

1. Step 1: Understand read concern levels

   local returns the most recent data on the node but does not wait for replication.

2. Step 2: Compare with other levels

   majority waits for data to be acknowledged by majority nodes, snapshot is for transactions, and linearizable is stricter and slower.

3. Final Answer:

   local -> Option A

4. Quick Check:

   Fastest read = local [OK]

Hint: Fastest read is always local [OK]

Common Mistakes:

• Confusing local with majority
• Thinking snapshot is fastest
• Assuming linearizable is default

2. Which of the following is the correct syntax to set read concern to majority in a MongoDB query?

easy

A. db.collection.find.readConcern('majority')

B. db.collection.find().readConcern = 'majority'

C. db.collection.find().readConcern('majority')

D. db.collection.find().withReadConcern('majority')

Solution

1. Step 1: Recall MongoDB read concern syntax

   The correct method to set read concern on a query is readConcern('level').

2. Step 2: Check options for syntax correctness

   Some options look similar, but one omits parentheses after find. The correct chaining is db.collection.find().readConcern('majority').

3. Final Answer:

   db.collection.find().readConcern('majority') -> Option C

4. Quick Check:

   Correct method call = db.collection.find().readConcern('majority') [OK]

Hint: Use .readConcern('level') after find() [OK]

Common Mistakes:

• Using assignment instead of method call
• Using non-existent method names
• Placing parentheses incorrectly

3. Given a MongoDB transaction using snapshot read concern, what will be the behavior if a document is updated after the transaction starts but before it reads the document?

medium

A. The transaction reads the updated document reflecting the change.

B. The transaction reads the document state as it was at the start of the transaction.

C. The transaction throws an error due to data inconsistency.

D. The transaction reads the document from the primary node only.

Solution

1. Step 1: Understand snapshot read concern in transactions

   snapshot ensures a consistent view of data as of the start of the transaction.

2. Step 2: Analyze document update timing

   Since the document was updated after the transaction started, the transaction will not see this change.

3. Final Answer:

   The transaction reads the document state as it was at the start of the transaction. -> Option B

4. Quick Check:

   snapshot = consistent start view [OK]

Hint: Snapshot reads see data as of transaction start [OK]

Common Mistakes:

• Assuming transaction sees latest updates
• Thinking snapshot causes errors on updates
• Confusing snapshot with majority read concern

4. You wrote this code snippet to set read concern to majority but it throws an error:

db.collection.find().readConcern = 'majority'

What is the error and how to fix it?

medium

A. No error, code is correct.

B. Error: readConcern must be set on the client, not query.

C. Error: 'majority' is not a valid read concern level.

D. Error: readConcern is a method, use readConcern('majority') instead.

Solution

1. Step 1: Identify the error cause

   Assigning a string to readConcern property is invalid because it is a method, not a property.

2. Step 2: Correct the syntax

   Use method call syntax: readConcern('majority') to set the read concern level.

3. Final Answer:

   Error: readConcern is a method, use readConcern('majority') instead. -> Option D

4. Quick Check:

   Use method call, not assignment [OK]

Hint: Use parentheses for readConcern, not assignment [OK]

Common Mistakes:

• Assigning string instead of calling method
• Setting read concern on wrong object
• Using invalid read concern levels

5. You want to ensure your MongoDB transaction reads a consistent snapshot of data and also that your reads outside transactions see only data confirmed by majority of nodes. Which read concern levels should you use respectively?

hard

A. snapshot for transactions, majority for outside reads

B. local for transactions, snapshot for outside reads

C. majority for transactions, local for outside reads

D. snapshot for transactions, local for outside reads

Solution

1. Step 1: Identify read concern for transactions

   snapshot read concern ensures consistent view inside transactions.

2. Step 2: Identify read concern for outside transactions

   majority ensures reads see data confirmed by majority of nodes, providing safety.

3. Final Answer:

   snapshot for transactions, majority for outside reads -> Option A

4. Quick Check:

   Transaction = snapshot, Outside = majority [OK]

Hint: Use snapshot in transactions, majority outside [OK]

Common Mistakes:

• Using local inside transactions
• Confusing majority with snapshot
• Using local for safe reads