New in version 3.6.
A query with read concern
"available" returns data from the instance
with no guarantee that the data has been written to a majority of the
replica set members (i.e. may be rolled back).
"available" is the default for reads against secondaries
if the reads are not associated with causally consistent sessions.
For a sharded cluster,
"available" read concern
provides greater tolerance for partitions since it does not wait to
ensure consistency guarantees. That is, read concern
"available" does not contact the shard's primary nor the
config servers for updated metadata. However, this means that a
"available" read concern may return
orphaned documents if the shard is
undergoing chunk migrations.
Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.
"available" is unavailable for use
with causally consistent sessions and transactions.
Consider the following timeline of a write operation Write 0 to a three member replica set:
For simplification, the example assumes:
- All writes prior to Write 0 have been successfully replicated to all members.
- Write prev is the previous write before Write 0.
- No other writes have occured after Write 0.
Most Recent Write
Most Recent w: "majority" write
Primary applies Write 0
Primary: Write 0