[SERVER-38617] Rollback via refetch can incorrectly timestamp index build writes Created: 13/Dec/18 Updated: 29/Oct/23 Resolved: 14/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| 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 | ||||
| Sprint: | Storage NYC 2018-12-17 | ||||
| Participants: | |||||
| Linked BF Score: | 65 | ||||
| Description |
|
Rollback via refetch goes through four steps before the node can return to the replica set as a functioning secondary:
All writes done while a node is in rollback state must be persisted before a node can persist a write that implies rollback has completed. This is the repl-storage rollback via refetch contract. Rolling back a dropIndexes command will recreate the index via the secondary code path. This will hit the code path that creates an IndexBuilder. When the IndexBuilder completes an index, it has to decide how the catalog write will be timestamped, potentially timestamping the write itself via the time on the LogicalClock. In the case of rollback, requiresGhostCommitTimestamp can return true. Additionally, there's no guarantee the LogicalClock time will be such that the write is persisted before the write that implies rollback is complete (the repl-storage rollback via refetch contract) . It's possible for the ready: true write to be too far in the future and not persisted on a restart. A restart would see an unfinished index and may drop it, which would result in an inconsistency with the rest of the replica set. |
| Comments |
| Comment by Githook User [ 14/Dec/18 ] |
|
Author: {'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb'}Message: |
| Comment by Daniel Gottlieb (Inactive) [ 13/Dec/18 ] |
|
Note this is not a problem for 3.6/4.0 rollback via refetch. Those versions enable WT table logging for all tables, thus the ready: true write will be persisted across a restart despite an unexpected timestamp. |