[SERVER-44634] Account for election down time when calculating majority committed lag Created: 14/Nov/19 Updated: 29/Oct/23 Resolved: 12/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Execution Team 2019-12-30, Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-04-20, Execution Team 2020-06-01, Execution Team 2020-06-15 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
According to the findings in These are the percentile breakdowns of the first majority committed write after a new term across 4.0 and 4.2. The units are in seconds:
|
| Comments |
| Comment by Githook User [ 12/Jun/20 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Connie Chen [ 03/Mar/20 ] |
|
This ticket needs further investigation, moving back to open until the next sprint starts |
| Comment by Lingzhi Deng [ 14/Nov/19 ] |
|
And judah.schvimer pointed out that this only works if the lastCommitted lag is one term behind. And if there are multiple elections in between, we don't know the aggregate "down time" due to those elections. Though, having the lag across multiple term changes presumably happens a lot less. I guess the question is how precise we want to be v.s. the benefit we would get for the extra complexity. |
| Comment by Maria van Keulen [ 14/Nov/19 ] |
|
ldeng proposed a solution to this issue where we approximate the "down time" of the replica set by determining the difference between the catch-up point of the new primary and the first OpTime of its new term. Majority committed lag calculations would subtract this difference from the calculation to avoid overstating the lag. Since we are interested in wall clock time lag, we would need to store the wall clock time corresponding to the first OpTime of the term in memory, and also store the wall clock time of the catch-up point. |