[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:
Duplicate
is duplicated by SERVER-31480 rollback_internal::updateFixUpInfoFro... Closed
Related
related to SERVER-31300 applyOps command should add collectio... Closed
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.

{  "ts" : Timestamp(1506545010, 7),  "t" : NumberLong(1),  "h" : NumberLong("1630858374415394653"),  "v" : 2,  "op" : "c",  "ns" : "admin.$cmd",  "wall" : ISODate("2017-09-27T20:43:30.627Z"),  "o" : {  "applyOps" : [ { "op" : "i", "ns" : "test.coll", "o" : { "_id" : 0 } }, { "op" : "i", "ns" : "test.coll2", "o" : { "_id" : 0 } } ],  "$readPreference" : {  "mode" : "secondaryPreferred" },  "$db" : "admin" }

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: SERVER-31295 Re-enable applyOps rollback test
Branch: master
https://github.com/mongodb/mongo/commit/5f92390347b64fd4ce501c39f78f853be107271c

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: SERVER-31295 SERVER-31489 Allow applyOps to rollback without UUID
Branch: master
https://github.com/mongodb/mongo/commit/999d491ed3b27d47dd0a8d9d86b4f7359f2dfae3

Comment by William Schultz (Inactive) [ 12/Oct/17 ]

Can re-enable testing of applyOps in jstests/replsets/rollback_all_op_types.js (SERVER-31130) once this ticket is completed.

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.

Generated at Thu Feb 08 04:26:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.