[SERVER-70752] Initial sync could crash on a node with unclean data if an oplog replay is triggered Created: 20/Oct/22 Updated: 05/Dec/22 Resolved: 25/Oct/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yuhong Zhang | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
When making a node with existing data to rejoin a replset with initial sync, triggering an oplog replay can crash the sync because writing down the top of the oplog entry which was already replicated to the sync node can have a conflicting timestamp with the stable timestamp. This is however an edge case and should not be done by the users. A crash is expected in this case. As a result, we would just want to fix the test. We can potentially prevent the sync source from writing down extra oplog entries during the initial sync. |
| Comments |
| Comment by Matt Kneiser [ 25/Oct/22 ] |
|
yuhong.zhang@mongodb.com will file a test fix to avoid generating the extra oplog entry. |