Read from secondaries trade-offs in MongoDB - Mini Project: Build & Apply

Understanding Read from Secondaries Trade-offs in MongoDB

📖 Scenario: You are managing a MongoDB database for an online bookstore. To improve read performance and reduce load on the primary server, you want to read data from secondary replicas. However, you need to understand the trade-offs involved in reading from secondaries, such as data consistency and replication lag.

🎯 Goal: Build a MongoDB query setup that reads book data from secondary replicas using readPreference. Learn how to configure the read preference and understand the impact on data freshness and consistency.

📋 What You'll Learn

Create a MongoDB collection named books with sample book documents.

Set a read preference variable to read from secondary replicas.

Write a query to find all books using the secondary read preference.

Add a final configuration to handle potential replication lag.

💡 Why This Matters

🌍 Real World

Reading from secondary replicas helps distribute read load and improve performance in real-world applications like online stores or social media platforms.

💼 Career

Understanding read preferences and replication lag is important for database administrators and backend developers to ensure data consistency and performance.

1

Create the books collection with sample data

Create a MongoDB collection called books and insert these exact documents: { title: "The Great Gatsby", author: "F. Scott Fitzgerald", year: 1925 }, { title: "1984", author: "George Orwell", year: 1949 }, and { title: "To Kill a Mockingbird", author: "Harper Lee", year: 1960 }.

MongoDB

// Insert the sample book documents into the books collection
// Your code here

Hint

Use db.books.insertMany() with an array of objects containing the exact book details.

2

Set the read preference to secondary

Create a variable called readPref and set it to { readPreference: "secondary" } to configure queries to read from secondary replicas.

MongoDB

db.books.insertMany([
  { title: "The Great Gatsby", author: "F. Scott Fitzgerald", year: 1925 },
  { title: "1984", author: "George Orwell", year: 1949 },
  { title: "To Kill a Mockingbird", author: "Harper Lee", year: 1960 }
])

// Create a variable readPref with readPreference set to 'secondary'
// Your code here

Hint

Use const readPref = { readPreference: "secondary" } to set the read preference.

3

Query the books collection using the secondary read preference

Write a query using db.books.find() with the readPref variable to read all documents from the secondary replicas.

MongoDB

db.books.insertMany([
  { title: "The Great Gatsby", author: "F. Scott Fitzgerald", year: 1925 },
  { title: "1984", author: "George Orwell", year: 1949 },
  { title: "To Kill a Mockingbird", author: "Harper Lee", year: 1960 }
])

const readPref = { readPreference: "secondary" }

// Use db.books.find() with readPref to read from secondary replicas
// Your code here

Hint

Use db.books.find({}, null, readPref) to query with the read preference.

4

Add a maxStalenessSeconds option to handle replication lag

Extend the readPref variable to include maxStalenessSeconds: 90 to limit how stale the data can be when reading from secondaries.

MongoDB

db.books.insertMany([
  { title: "The Great Gatsby", author: "F. Scott Fitzgerald", year: 1925 },
  { title: "1984", author: "George Orwell", year: 1949 },
  { title: "To Kill a Mockingbird", author: "Harper Lee", year: 1960 }
])

// Update readPref to include maxStalenessSeconds: 90
const readPref = { readPreference: "secondary" }

const booksFromSecondary = db.books.find({}, null, readPref)

// Your code here

Hint

Add maxStalenessSeconds: 90 inside the readPref object.

Practice

1. What is a main advantage of reading data from secondary nodes in a MongoDB replica set?

easy

A. It helps balance the read load and can improve read speed.

B. It guarantees the freshest data with zero delay.

C. It prevents any replication lag from occurring.

D. It disables writes to the primary node.

Solution

1. Step 1: Understand the role of secondaries in MongoDB

   Secondary nodes replicate data from the primary and can serve read requests to reduce load on the primary.

2. Step 2: Identify the benefit of reading from secondaries

   Reading from secondaries balances read load and can improve read speed, but data might be slightly stale.

3. Final Answer:

   It helps balance the read load and can improve read speed. -> Option A

4. Quick Check:

   Reading from secondaries = load balancing and faster reads [OK]

Hint: Secondaries help with read speed but may lag [OK]

Common Mistakes:

• Thinking secondaries always have the freshest data
• Assuming secondaries prevent replication lag
• Believing reading from secondaries disables writes

2. Which of the following is the correct way to set a read preference to read from secondary nodes in MongoDB using the shell?

easy

A. db.collection.find().readPreference('secondary')

B. db.collection.find().setReadPref('primary')

C. db.collection.find().readPreference('primaryPreferred')

D. db.collection.find().readPreference('secondaryPreferred')

Solution

1. Step 1: Recall MongoDB read preference options

   MongoDB supports 'primary', 'primaryPreferred', 'secondary', and 'secondaryPreferred' as read preferences.

2. Step 2: Identify correct syntax for reading from secondaries

   To read from secondaries but allow fallback to primary, use 'secondaryPreferred'. The method is .readPreference('secondaryPreferred').

3. Final Answer:

   db.collection.find().readPreference('secondaryPreferred') -> Option D

4. Quick Check:

   Use .readPreference('secondaryPreferred') to read from secondaries [OK]

Hint: Use 'secondaryPreferred' to read from secondaries safely [OK]

Common Mistakes:

• Using 'secondary' which fails if no secondary is available
• Confusing 'primaryPreferred' with reading from secondaries
• Using incorrect method names like setReadPref

3. Consider a MongoDB replica set with some replication delay. If you run a query with read preference set to secondary, what is the most likely outcome?

medium

A. You get the freshest data always from the primary.

B. You might get slightly stale data due to replication lag.

C. The query will fail if the primary is down.

D. The query will always return an error if secondaries exist.

Solution

1. Step 1: Understand replication lag in secondaries

   Secondaries replicate data asynchronously, so there can be a delay causing stale data.

2. Step 2: Analyze read preference 'secondary'

   Reading from secondaries means data may not be the freshest due to replication lag.

3. Final Answer:

   You might get slightly stale data due to replication lag. -> Option B

4. Quick Check:

   Reading from secondaries = possible stale data [OK]

Hint: Secondary reads can be stale due to lag [OK]

Common Mistakes:

• Assuming secondary reads always return fresh data
• Thinking queries fail if primary is down when reading from secondary
• Believing reading from secondaries causes errors if secondaries exist

4. You set your MongoDB client to read from secondaries using readPreference: 'secondary', but your application sometimes gets errors when no secondaries are available. How can you fix this?

medium

A. Remove read preference to always read from primary.

B. Set read preference to 'primary' to avoid errors.

C. Change read preference to 'secondaryPreferred' to allow fallback to primary.

D. Restart the MongoDB server to fix the errors.

Solution

1. Step 1: Identify cause of errors

   Using 'secondary' read preference causes errors if no secondary nodes are available.

2. Step 2: Choose a read preference that allows fallback

   'secondaryPreferred' reads from secondaries if available, else falls back to primary, preventing errors.

3. Final Answer:

   Change read preference to 'secondaryPreferred' to allow fallback to primary. -> Option C

4. Quick Check:

   Use 'secondaryPreferred' to avoid errors when no secondaries [OK]

Hint: Use 'secondaryPreferred' to avoid errors if no secondaries [OK]

Common Mistakes:

• Switching to 'primary' loses read load balancing benefits
• Removing read preference may not fix fallback issues
• Restarting server does not solve read preference errors

5. Your application requires fast reads but can tolerate slightly stale data. You want to minimize load on the primary node. Which read preference should you choose and why?

hard

A. Use 'secondaryPreferred' to read from secondaries when available, else primary, balancing load and freshness.

B. Use 'secondary' to read only from secondaries, balancing load but risking stale data.

C. Use 'primaryPreferred' to always read from primary regardless of load.

D. Use 'primary' to ensure freshest data and reduce load on secondaries.

Solution

1. Step 1: Analyze application needs

   The app wants fast reads, can accept some stale data, and wants to reduce primary load.

2. Step 2: Evaluate read preference options

   'secondary' risks errors if no secondaries; 'secondaryPreferred' reads from secondaries if available, else primary, balancing load and freshness.

3. Step 3: Choose best option

   'secondaryPreferred' fits best as it balances load and freshness with fallback.

4. Final Answer:

   Use 'secondaryPreferred' to read from secondaries when available, else primary, balancing load and freshness. -> Option A

5. Quick Check:

   'secondaryPreferred' balances load and freshness [OK]

Hint: Choose 'secondaryPreferred' for load balance and fallback [OK]

Common Mistakes:

• Choosing 'primary' ignores load balancing
• Choosing 'secondary' risks errors if no secondaries
• Choosing 'primaryPreferred' ignores secondary reads