[SERVER-15091] Reduce replication lag when primary is overloaded Created: 29/Aug/14 Updated: 06/Dec/22 Resolved: 21/Apr/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Davide Italiano | Assignee: | Backlog - Replication Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | 28qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
Reproducible deterministically. After a bit the load is run on the primary rs.status() will report optimeDate on any of the secondary being far behind the one of the primary. Can be reproduced even with a 3-members replica set all in the same availability zone, in an AWS datacenter. Get linkbench from https://github.com/dcci/linkbench and run
Relevant configuration bits into LinkConfigMongodb.properties
or higher |
| Comments |
| Comment by Eric Milkie [ 21/Apr/16 ] |
| Comment by Eric Milkie [ 29/Aug/14 ] |
|
The work for this ticket will involve investigating the reason why the secondary falls behind so rapidly for this workload, and then explore options to improve this if we deem it valuable. |