Docs Home → Develop Applications → MongoDB Manual
Read Concern "available"
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:
Availability
Read concern "available" is unavailable for use
with causally consistent sessions and transactions.
Example
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.
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.
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 |