-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
Fully Compatible
-
QuInt A (10/12/15)
-
0
Do not wait for the apply of the oplog entries before recording them in the oplog. This means both of these operation can be done concurrently instead of serially now that we record the boundaries of the batch and recover correctly but removing the oplog entries record during failures.
old description
Inserts into the oplog on the primary are done in parallel by each connection thread, whereas they are done on the secondary serially by the sync thread. This means that the oplog inserts are considerably slower on the secondary, which can create replication lag. See this comment for more information.
- depends on
-
SERVER-20655 During recovery replicas should truncate the oplog to start position of the failed batch
- Closed
-
WT-1979 Lower performance of out-of-order inserts can contribute to replication lag
- Closed
-
SERVER-20326 Record "apply" batch boundaries during replication
- Closed
- is depended on by
-
SERVER-18908 Secondaries unable to keep up with primary under WiredTiger
- Closed
- related to
-
SERVER-21858 A high throughput update workload in a replica set can cause starvation of secondary reads
- Closed