[SERVER-14866] Replication from 2.4 primary to 2.6 secondaries failes on missing db in system.users Created: 12/Aug/14  Updated: 10/Dec/14  Resolved: 15/Aug/14

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

Type: Bug Priority: Major - P3
Reporter: Robin Speekenbrink Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to DOCS-3899 Clarify that all user data is immutab... Closed
related to SERVER-14887 Allow user document changes made on a... Closed
Operating System: ALL
Steps To Reproduce:

have a 2.4(.10) primary with a 2.6(.3) secondary and update a user inside a database system.users :

{
"_id": ObjectId("52cd1973dd44e5b4fe9c84b7"),
"user": "test",
"pwd": "testpassword",
"roles": [
"read",
"readWrite"
]
}

Participants:

 Description   

I'm following the rolling upgrade procedure for upgrading my replication set to 2.6 (coming from 2.4)

This works like it should except when encountering user credential updates...
This does not work in a backwards compatible way (due to the new system.users layout...)

2014-08-12T11:54:58.653+0200 [repl writer worker 3] ERROR: writer worker caught exception:  :: caused by :: 2 User document needs 'db' field to be a non-empty string on: { ts: Timestamp 1407584109000|1, h: 1483884049638091315, v: 2, op: "u", ns: "communibase_noloc_test.system.users", o2: { _id: ObjectId('52cd1973dd44e5b4fe9c84b7') }, o: { _id: ObjectId('52cd1973dd44e5b4fe9c84b7'), user: "xWdMA8qmytKAc7m", pwd: "a456218d1d878d9d53963503af28b328", roles: [] } }
2014-08-12T11:54:58.654+0200 [repl writer worker 3] Fatal Assertion 16360
2014-08-12T11:54:58.654+0200 [repl writer worker 3] 
 
***aborting after fassert() failure

Is there any way to have 2.6 secondaries without forcing the primary directly to 2.6 too?



 Comments   
Comment by Robin Speekenbrink [ 15/Aug/14 ]

Spencer,

Thanks for the update and the clearification. This indeed is not reflected by the documentation at all: its supposed to be a full on backwards compatible change (i.e. http://docs.mongodb.org/manual/release-notes/2.6-upgrade-authorization/#timing where it's advised to leave the incompatible state for a while)

Anyway, this has forced us to upgrade the remaining mongod-instances to 2.6 .... To bad the rolling update process wasn't really that rolling

Thanks again for the udpate!

Comment by Spencer Brody (Inactive) [ 13/Aug/14 ]

Hi Robin,

Unfortunately this is the expected behavior. Due to the new schema for user documents in 2.6, once you have begun upgrading to 2.6, all user data is immutable until every node is on 2.6 and you have run the authorization data schema upgrade. Your full replica set must either be all on 2.4 or 2.6 if you want to be able to modify user definitions.

I have filed DOCS-3899 to make this behavior clearer in our online documentation, and SERVER-14887 requesting we make this behavior better in our next 2.6 minor release.

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