Lesson 5: Read and Write Concerns with MongoDB Deployments / Learn

Video Transcript (English)

Working with multiple instances of MongoDB poses unique scenarios when issuing read and write operations. In this video, you’ll learn what read and write concerns do, how read preferences work, and how to configure them.

In a replica set, the write concern describes how many data-bearing members need to acknowledge a write before it's considered complete. Higher levels of acknowledgement produce a stronger durability guarantee.

Durability ensures that data that has been committed to the database will not be lost in the event of a failover.

There are several options for write concerns.

By default, MongoDB uses a write concern of majority. This means that a majority of the members of a replica set are required to persist the write operation before it’s acknowledged.

We can instead provide a write concern with a number that represents the number of members needed to perform a write operation. For example, a write concern of 1 means that we require only the primary to deem the operation successful.

If we have a write concern of majority on a three-member replica set, two of the three members need to successfully perform the write for it to be considered successful.

Without a majority of the members’ successful write, the write might not be durable.

Now let’s talk about how to configure write concerns.

One way is to do so directly on a single operation.

Let’s take a look at an example.

Here, we’re inserting a single document that represents our colleague’s beloved black cat Mac. Within the insertOne() method, we pass in a second document that sets the write concern to majority and the write timeout to 3000 milliseconds. The write timeout ensures that our operation won’t be blocked indefinitely.

Now we’ll hop over to the shell, which is currently connected to a replica set.

First, we're going to switch to a new database called pets. And then we're going to insert a new document into it. This is now switched my active database. And I'm going to insert into pets into a new cats collection a single document.

This document will have the name "Mac" with a color "black" and an age of "6." And this write is going to use a write concern of majority with a timeout of 3,000 seconds.

As with any other insertOne command, we do get a return document that acknowledges the insertion of our document to the collection.

In addition to write concerns, there are also read concerns.

Read concerns allow your application to specify a durability guarantee for the documents that are returned by a read operation.

Through the effective use of write and read concerns, you can adjust the level of consistency and availability guarantees as appropriate, such as waiting for stronger consistency guarantees or loosening consistency requirements to provide higher availability.

You can choose between returning the most recent data in the cluster or returning only the data committed by a majority of the replica set.

There are a few different read concern levels. But in this video, we'll cover the four most common ones: local, available, majority, and linearizable.

By default, MongoDB uses the local read concern, which returns the most recent data.

Majority returns only data that has been acknowledged as written by a majority of the replica set.

A linearizable read concern reflects all successful majority-acknowledged writes that were completed before the start of the read operation.

Finally, the available read concern is the same as a local read concern of four replica sets.

To change the default read and write concern on the cluster for all users, we first connect to the admin database. Then we issue an admin command by using a document with the following keys: setDefaultRWConcern, defaultReadConcern,and defaultWriteConcern.

setDefaultRWConcern is the name of the admin command that we're going to issue.

Its value is always set to 1.

We set the defaultReadConcern to majority.

This ensures that every document that we're reading is durable.

We also set the defaultWriteConcern to majority.

This ensures that if an operation is committed, it has been acknowledged by a majority of the members of a replica set.

Back in the shell, we'll switch back to the admin database. Then we'll paste in this admin command. This command will allow us to set the default read and write concern, the default read concern, and the default write concern for our database.

When we run this command, we do get a return document tthat confirms our changes.

Now that you know what read concerns are, let's discuss read preferences.

Read preference describes which members of a replica set you want to send your read operation to.

There are a few options for your read preferences. By default, the read preference is set to primary, which means that all of the reads go to the primary member of the replica set.

There's also an option called primaryPreferred, which attempts to read from a primary.

But if the primary is unavailable for some reason, the operation can go to a secondary.

There's also an option called secondary, which reads from our secondaries, and secondaryPreferred, which will attempt tto read from a secondary but if one is not available can read from the primary.

Something to keep in mind when you're reading from a secondary is that you do have a chance of returning stale data.

Finally, there is a nearest option, which will direct all of your reads to the member with the nearest network ping.

The nearest read option is useful if you want to support geographically local reads, which can improve your latency.

One way to set the read preference is to append it to our options in our connection string.

In this example, we're reading from the secondary.

Additionally, we can set a time limit for how stale our data can be. In this case, we set it to 120 seconds, which means that it won't be more than 120 seconds behind.

Amazing work.

You learned a lot this lesson.

Let's do a quick recap.

First, we covered how to set write concerns for our individual operations.

Then you learned about read concerns and how to set both read concerns and write concerns globally for a database.

Finally, we added read preferences to the connection string.