Read Concern "available"

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).

Read concern “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. However, a query with "available" read concern may return orphan documents if the shard is undergoing chunk migrations since the "available" read concern, unlike "local" read concern, does not contact the shard’s primary nor the config servers for updated metadata.

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

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.

Causally Consistent Sessions

Read concern available is unavailable for use with causally consistent sessions.

Example

Consider the following timeline of a write operation Write0 to a three member replica set:

Note

For simplification, the example assumes:

  • All writes prior to Write0 have been successfully replicated to all members.

  • Writeprev is the previous write before Write0.

  • No other writes have occured after Write0.

Timeline of a write operation to a three member replica set.

TimeEventMost Recent WriteMost Recent w: “majority” write
t0Primary applies Write0Primary : Write 0
Secondary 1: Write prev
Secondary 2: Write prev
Primary : Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t1Secondary1 applies write0Primary : Write 0
Secondary 1: Write 0
Secondary 2: Write prev
Primary : Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t2Secondary2 applies write0Primary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary : Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t3Primary is aware of successful replication to Secondary1 and sends acknowledgement to clientPrimary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary : Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t4Primary is aware of successful replication to Secondary2Primary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary : Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t5Secondary1 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: “majority” writePrimary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary : Write 0
Secondary 1: Write 0
Secondary 2: Write prev
t6Secondary2 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: “majority” writePrimary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary : Write 0
Secondary 1: Write 0
Secondary 2: Write 0

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

Timeline of a write operation to a three member replica set.

Read TargetTime TState of Data
PrimaryAfter t0Data reflects Write0.
Secondary1Before t1Data reflects Writeprev
Secondary1After t1Data reflects Write0
Secondary2Before t2Data reflects Writeprev
Secondary2After t2Data reflects Write0