Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

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

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 query with "available" read concern may return orphaned documents if the shard is undergoing chunk migrations.

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.

Tip

See also:

Read concern "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:

Note

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.

Timeline of a write operation to a three member replica set.
Time
Event
Most Recent Write
Most Recent w: "majority" write
t 0
Primary applies Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 1
Secondary 1 applies write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 2
Secondary 2 applies write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write prev
Secondary 1: Write prev
Secondary 2: Write prev
t 3
Primary is aware of successful replication to Secondary 1 and sends acknowledgement to client
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t 4
Primary is aware of successful replication to Secondary 2
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write prev
Secondary 2: Write prev
t 5
Secondary 1 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write 0
Primary: Write 0
Secondary 1: Write 0
Secondary 2: Write prev
t 6
Secondary 2 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: "majority" write
Primary: 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 Target
Time T
State of Data
Primary
After t 0
Data reflects Write 0.
Secondary 1
Before t 1
Data reflects Write prev
Secondary 1
After t 1
Data reflects Write 0
Secondary 2
Before t 2
Data reflects Write prev
Secondary 2
After t 2
Data reflects Write 0
←  Read Concern "local"Read Concern "majority" →