[SERVER-31189] fassert if feature compatibility version changes during rollback Created: 20/Sep/17  Updated: 30/Oct/23  Resolved: 20/Oct/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.6.0-rc1

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31019 Changing fCV during initial sync lead... Closed
depends on SERVER-31531 feature compatibility version writes ... Closed
Related
related to SERVER-31426 Fail write to fCV document if admin.s... Closed
related to SERVER-31805 rollbackViaRefetchNoUUID fails if rol... Closed
is related to SERVER-31384 applyOps should propagate oplog appli... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-10-02, Repl 2017-10-23
Participants:

 Description   

Rollback will not work if there are a mix of UUID and non-UUID operations in the oplog.



 Comments   
Comment by Githook User [ 20/Oct/17 ]

Author:

{'email': 'judah@mongodb.com', 'name': 'Judah Schvimer', 'username': 'judahschvimer'}

Message: SERVER-31189 SERVER-31426 fail rollback on downgrade
Branch: master
https://github.com/mongodb/mongo/commit/b3d26b5f94636870f75b92582d6b7c31190a1295

Comment by Judah Schvimer [ 02/Oct/17 ]

This is not a problem for upgrade since we will use the "rollback via refetch with no UUIDs" algorithm while in fCV 3.4 and only start using the UUID version once the last UUID collMod cannot be rolled back.

As a result, we only need to crash on downgrade. Since this is an uncommon scenario, we will simplify this ticket to crash anytime we see a downgrade op when not in SECONDARY.

Comment by Judah Schvimer [ 20/Sep/17 ]

We actually have to see what's happening on the sync source, which makes this more complicated. If the sync source downgrades during rollback then rollback's queries by UUID will fail even though the documents exist. I'm not sure if we error or ignore the "missing document" in this case since it would look identical to the collection being dropped on the sync source, which should just be ignored.

If the only fCV/schema version change is on the rolling back node, we may actually be fine just using "rollback via refetch without UUIDs".

Comment by Eric Milkie [ 20/Sep/17 ]

By "changes", do you mean an update to the admin.system.version collection is rolled back? I feel like that's the only way the FCV value could change.

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