[SERVER-47219] Correct downgrade_after_rollback_via_refetch to not binary downgrade on crash Created: 01/Apr/20 Updated: 29/Oct/23 Resolved: 28/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc2, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2020-04-06, Execution Team 2020-05-04 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 50 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comments |
| Comment by Githook User [ 28/Apr/20 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Alex Cameron (Inactive) [ 23/Apr/20 ] |
|
As we discussed, the solution here is going to be to disable this test until majority reads are removed. Assigning back to execution team backlog. |
| Comment by Githook User [ 17/Apr/20 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Daniel Gottlieb (Inactive) [ 17/Apr/20 ] |
|
kelsey.schubert Yep, it's going in now. |
| Comment by Kelsey Schubert [ 16/Apr/20 ] |
|
Can we push to 4.4 now and forward port after |
| Comment by Daniel Gottlieb (Inactive) [ 15/Apr/20 ] |
|
I'm marking this as depends on |
| Comment by Luke Chen [ 08/Apr/20 ] |
|
daniel.gottlieb |
| Comment by Daniel Gottlieb (Inactive) [ 02/Apr/20 ] |
|
tess.avitabile and I talked and our approach to fix this was to perform a clean shutdown. A clean shutdown though falls into this clause that effectively circumvents the downgrade process. After some poking, we concluded that startup replication recovery is in fact resilient to idempotency problems due to potentially re-applying oplog entries. With that, we're confident that performing an untimestamped checkpoint[1] (given the appropriate minValid/appliedThrough values) is sufficient for allowing the data to downgrade correctly to 4.2. However, the current tip of 4.2 is unable to open the datafiles because of a bug described in [1] There's some considerations about when this checkpoint is taken depending on how much code we want to change. That will be decided when the ticket is unblocked. |