readConcern

WiredTiger supports multiple readConcern levels. Just like writeConcern, which is supported by every storage engine in MongoDB, with readConcern, we can customize how many servers in a replica set must acknowledge the query results for the document to be returned in the result set.

Available options for read concern are as follows:

  • local: Default option. Will return most recent data from the server. Data may, or may not, have propagated to the other servers in a replica set, and we run the risk of a rollback.
  • linearizable:
    • Only applicable for reads from the primary
    • Only applicable in queries that return a single result
    • Data returns satisfy two conditions:
      • majority, writeConcern
      • Data was acknowledged before the start of the read operation

In addition, if we have set writeConcernMajorityJournalDefault to true, we are guaranteed that the data won't get rolled back.

If we have set writeConcernMajorityJournalDefault to false, MongoDB will not wait for majority writes to be durable before acknowledging the write. In this case our data may be rolled back in the event of a loss of a member from the replica set. Data returned has already been propagated and acknowledged from majority of the servers before read has started.

We need to use maxTimeMS when using linearizable and majority read concern levels in case we can't establish majority writeConcern to avoid blocking, forever waiting for the response. In this case, the operation will return a timeout error.

MMAPv1 is the older storage engine and is considered, in many aspects, as being deprecated, but many deployments are still using it.

local and linearizable read concerns are available for MMAPv1 as well.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset