MongoDB 4.0: Non-Blocking Secondary Reads

MongoDB 4.0: Non-Blocking Secondary Reads

Many MongoDB users read from secondary replica set members to scale-out read throughput, and reduce network latency using the nearest read preference.

Ensuring reads never return data that is not in the same causal order as the primary replica, MongoDB blocks readers while oplog entries are applied in batches to the secondary. This can cause secondary reads to have variable latency, especially when bulk loading new data. Why does MongoDB do this? When applying a sequence of writes to a document, then MongoDB is designed so that each of the replicas must show those writes in the same causal order. So if you change field "A" and then field "B", it isn’t possible to see that document with changed field "B" and not changed field "A". Eventually consistent systems suffer from this behavior, but MongoDB does not.

Using storage engine timestamps and snapshots implemented for multi-document ACID transactions, secondary reads in MongoDB 4.0 become non-blocking. Queries against secondaries now read from a snapshot of data while replication batches are simultaneously applied to the secondary. Reading from that snapshot guarantees a consistent view of the data, and since applying current writes via a replication batch doesn't change the earlier snapshots, we can relax the lock that replication uses to allow secondary reads. As a result, you get predictable, low read latencies and increased throughput from the replica set.

You can learn more about secondary reads and other new features in our Guide to What’s New in MongoDB 4.0