-
Type: Improvement
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
(copied to CRM)
Currently replication applies batches of oplog entries holding a lock to ensure that no reads can consume data which is not in the same causal order as the primary.
Instead of locking and blocking readers we can instead use a snapshot for reads from the last consistent replication state and essentially hide all writes until we reach a new consistent state. In addition to detaching replication writes from affecting readers (both users and other replicas) this also allows storage engines to optimize writing of replicated data to improve performance and reduce IO, since all replicated data is transient and disposable until committed.
- duplicates
-
SERVER-34192 Secondary reads during batch applications
- Closed
- is duplicated by
-
SERVER-21858 A high throughput update workload in a replica set can cause starvation of secondary reads
- Closed
-
SERVER-24661 Secondary block reader a very long time when replay oplog
- Closed
- is related to
-
SERVER-25168 Foreground index build blocks all R/W on ALL database on a sharded cluster with secondaryPreferred read preference
- Closed
-
SERVER-5729 Special-case concurrency model for oplog, make reads not block as much
- Closed
-
SERVER-6883 index creation on secondaries need not block readers
- Closed
-
SERVER-29123 Why is ParallelBatchWriterMode used when Applying Oplogs
- Closed
-
SERVER-31359 when large inserts into mongo, lots of global lock occur
- Closed
- related to
-
WT-2649 Some way to indicate valid points in the WT log
- Closed
-
SERVER-21862 Use record store directly to read from oplog for replication
- Closed