• "available"

Read Concern "available"

New in version 3.6.

A query with read concern “available” returns data from the instancewith no guarantee that the data has been written to a majority of thereplica set members (i.e. may be rolled back).

Read concern “available” is the default for reads against secondariesif the reads are not associated with causally consistent sessions.

For a sharded cluster, "available" read concern providesgreater tolerance for partitions since it does not wait to ensureconsistency guarantees. However, a query with"available" read concern may return orphaneddocuments if the shard is undergoing chunkmigrations since the "available" read concern, unlike"local" read concern, does not contact the shard’sprimary nor the config servers for updated metadata.

For unsharded collections (including collections in a standalonedeployment or a replica set deployment), "local" and"available" read concerns behave identically.

Regardless of the read concern level, the most recent data on anode may not reflect the most recent version of the data in the system.

See also

orphanCleanupDelaySecs

Causally Consistent Sessions

Read concern available is unavailable for use withcausally consistent sessions.

Example

Consider the following timeline of a write operation Write₀ toa three member replica set:

Note

For simplification, the example assumes:

• All writes prior to Write0 have been successfullyreplicated to all members.
• Writeprev is the previous write before Write0.
• No other writes have occured after Write0.

Then, the following tables summarizes the state of the data that a readoperation with "available" read concern would see attime T.