-
Type: Improvement
-
Resolution: Done
-
Priority: Critical - P2
-
None
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
Fully Compatible
-
Repl B (10/30/15), Repl C (11/20/15), Repl D (12/11/15)
-
0
On secondaries in PV1, replicated writes require waiting for journaling before updating their oplog position, for correctness. This change has caused performance and throughput to drop relative to the old PV0 replication process, as show below when PV1 became the default for replica sets.
Version, Primary inserts/s, Secondary inserts/s, Ratio
3.1.8 101790 / 259431 = 39.23% git 21c6a57 100623 / 260348 = 38.64% git c101632 111042 / 272315 = 40.77% git bf22ad1 105979 / 268666 = 39.44% [SERVER-20438: Stash pointer to _uncommittedRecordIds to get O(1) delete] git 92e38e6 100365 / 306215 = 32.77% git 0c001db 92363 / 324666 = 28.44% git 3f273cf 98546 / 328241 = 30.02% [Apply oplog and record in oplog concurrently] git 3937e8 130399 / 326500 = 39.93% git ca4481c 125779 / 333166 = 37.75% git 1cd101f 129144 / 334833 = 38.56% [New replica set configurations have protocolVersion=1 by default] git d789bca 84857 / 338166 = 25.09% git 4372e7b 81938 / 334853 = 24.47% [REVERT: Apply oplog and record in oplog concurrently] git f25e8ac 60469 / 335713 = 18.01% git 32844e3 62481 / 324500 = 19.25% 3.1.9 61854 / 334666 = 18.48% 3.2.0-rc0 83754 / 326486 = 25.65%
- depends on
-
SERVER-21129 Allow pipelining of applier work before updating-position/reporting
- Closed
-
SERVER-21155 Only parse oplog entries once during replication (apply phase)
- Closed
-
SERVER-21229 Group replicated inserts/deletes during apply
- Closed
-
SERVER-21250 Improve read throughput of oplog when tailing for replication
- Closed
-
SERVER-23046 Reimplement operation pipelining applier work before updating-position/reporting
- Closed
- related to
-
SERVER-21237 ReplSetTest.prototype.awaitReplication reads directly from the oplog collection causing false positives
- Closed
-
SERVER-21154 Prepare Apply Batches Outside of Applier Thread
- Closed