[SERVER-66207] Investigate throttling large write operations that create majority commit lag Created: 04/May/22 Updated: 14/Jun/22 Resolved: 14/Jun/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Josef Ahmad |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Sprint: | Execution Team 2022-05-30, Execution Team 2022-06-13, Execution Team 2022-06-27 | ||||
| Participants: | |||||
| Description |
|
For large write operations that generate many oplog entires, say, a large multi-delete, investigate strategies to prevent secondaries from falling too far behind. Flow control doesn't sufficiently account for this because it throttles operations globally, and only after lag has reached 5 seconds. The idea here is to force operations that have written large amounts of data to periodically wait for their writes to majority-replicate before writing any more. In this way, we don't penalize smaller write operations, and only make problematic operations back off. |