[SERVER-34381] 3.6 Majority read concern can read data mid-rollback Created: 09/Apr/18 Updated: 27/Oct/23 Resolved: 18/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
In 3.6, we do not prevent majority reads at a timestamp between the common point and reaching minValid. The data is inconsistent during this period of time, so we should not service reads that use timestamps during this period. This is only a problem for rollback via refetch. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 18/Apr/18 ] |
|
In 3.6 we maintain a list of _stableTimestampCandidates which only get set to optimes that are consistent (i.e. when we're not less than our minvalid). We then only update our committed snapshot (which is what we use to serve majority reads) to stable timestamp candidates. So I think we're safe from this. |
| Comment by Gregory McKeon (Inactive) [ 12/Apr/18 ] |
|
This may be a problem for majority readConcern on the inmemory storage engine in 4.0 as well. |