[SERVER-14887] Allow user document changes made on a 2.4 primary to replicate to a 2.6 secondary Created: 13/Aug/14  Updated: 11/Mar/15  Resolved: 18/Sep/14

Status: Closed
Project: Core Server
Component/s: Replication, Security
Affects Version/s: 2.6.4
Fix Version/s: 2.6.5, 2.7.7

Type: Bug Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-14866 Replication from 2.4 primary to 2.6 s... Closed
is related to SERVER-15360 User document changes made on a 2.4 p... Closed
Tested
tested by SERVER-15515 New test for mixed version replSet, 2... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Backport Completed:
Participants:

 Description   

Once you have upgraded to 2.6, user data is immutable until you run the user data upgrade. This is necessary and by design. However, it should be possible to allow user updates made in a mixed-mode cluster on a 2.4 primary to still replicate to a 2.6 secondary without crashing the 2.6. At the very least we should detect this and go into RECOVERING with a useful error message, rather than simply fasserting().



 Comments   
Comment by Githook User [ 18/Sep/14 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}

Message: SERVER-14887 Remove user document validation from the storage layer.

User documents are validated in the user management commands, validating them in the storage layer
makes the system less flexible and causes problems with mixed-version replica sets.
Branch: v2.6
https://github.com/mongodb/mongo/commit/aff4ae5f1da121fb94f01cb4e278a4596ec7856a

Comment by Githook User [ 18/Sep/14 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}

Message: SERVER-14887 Remove user document validation from the storage layer.

User documents are validated in the user management commands, validating them in the storage layer
makes the system less flexible and causes problems with mixed-version replica sets.
Branch: master
https://github.com/mongodb/mongo/commit/9ad364efb8bfd01d5653a8d085e23c70a0dcfb29

Comment by Robin Speekenbrink [ 10/Sep/14 ]

If this would allow a more safe rolling upgrade that would allow people (like myself) to more easily keep up with the times and upgrade to the new versions as they come out ...

Thanks for the heads up and hope to see this into 2.6 (although it was too late for me personally)

Comment by Spencer Brody (Inactive) [ 09/Sep/14 ]

Looks like this could be done just by removing the block here: https://github.com/mongodb/mongo/blob/master/src/mongo/db/catalog/collection.cpp#L321

There's actually already a comment that we were planning on removing that anyway. I believe our motivation was that all validation now happens in the user management commands, thus we shouldn't be validating the schema of user documents at the storage layer, which can cause problems like this. So I take it back, I actually think this would make sense to do in 2.7.x as well, and then backport to 2.6. Should not take long at all to do (though as always there will be a CAP cost)

Generated at Thu Feb 08 03:36:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.