[SERVER-31295] Rollback of applyOps fails since oplog entry has no UUID field Created: 27/Sep/17 Updated: 30/Oct/23 Resolved: 23/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | William Schultz (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: | Repl 2017-10-23, Repl 2017-11-13 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The applyOps command generates an oplog entry without a UUID so, in rs_rollback.cpp, we will crash when we try to dereference an optional UUID type during rollback of an applyOps oplog entry. This is an example of a raw applyOps oplog entry that contains two document inserts.
Rollback should treat applyOps oplog entries as special cases that don't require collection UUID oplog entry fields (there may be multiple operations, each with a different collection UUID, so it wouldn't really make sense for the applyOps entry to have a collection UUID). |
| Comments |
| Comment by Githook User [ 23/Oct/17 ] |
|
Author: {'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}Message: |
| Comment by Katherine Walker (Inactive) [ 20/Oct/17 ] |
|
Reassigning to william.schultz to add the jstest coverage |
| Comment by Githook User [ 20/Oct/17 ] |
|
Author: {'email': 'katherine.walker@mongodb.com', 'name': 'Katherine Walker', 'username': 'kvwalker'}Message: |
| Comment by William Schultz (Inactive) [ 12/Oct/17 ] |
|
Can re-enable testing of applyOps in jstests/replsets/rollback_all_op_types.js ( |
| Comment by Spencer Brody (Inactive) [ 10/Oct/17 ] |
|
dbCheck isn't a supported feature in 3.6 and is disabled in prod environments, so I think it's fine to leave broken wrt rollback for now. |
| Comment by Judah Schvimer [ 10/Oct/17 ] |
|
This will also occur for dbCheck. |
| Comment by Judah Schvimer [ 28/Sep/17 ] |
|
This will also occur for dropDatabase. |
| Comment by William Schultz (Inactive) [ 27/Sep/17 ] |
|
Yep, that sounds like the right approach. I will make that task a separate ticket. |
| Comment by Andy Schwerin [ 27/Sep/17 ] |
|
The applyOps command should add uuids to the contained operations in the applyOps oplog entry. |
| Comment by William Schultz (Inactive) [ 27/Sep/17 ] |
|
This issue seems to have been introduced when we made 3.6 rollback compatible with UUIDs, meaning it would only affect the rollbackViaRefetch algorithm. |