[SERVER-25969] When featureCompatibilityVersion is 3.2, a 3.4 node can't initial sync decimal data Created: 06/Sep/16  Updated: 19/Nov/16  Resolved: 20/Sep/16

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

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

Issue Links:
Depends
Gantt Dependency
has to be done before SERVER-25725 Running {setFeatureCompatibilityVersi... Closed
Related
related to SERVER-25131 CollectionBulkLoaderImpl should relea... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query 2016-09-19, Query 2016-10-10
Participants:
Linked BF Score: 0

 Description   

If the primary has featureCompatibilityVersion 3.4, and during initial sync, we copy over decimal data before copying admin.system.version, then we reject the decimal data, and the initial sync fails.

We would also like to successfully initial sync from a primary with featureCompatibilityVersion 3.2 that has decimal data, since a user can get into this state by inserting decimal data and then setting featureCompatibilityVersion to 3.2.



 Comments   
Comment by Githook User [ 20/Sep/16 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-25969 make slaves and secondaries always use BSON 1.1 validation

This allows secondaries and slaves to sync NumberDecimal even while
in featureCompatibilityVersion:"3.2" mode.
Branch: master
https://github.com/mongodb/mongo/commit/2ac0e07e7f82406e989fa272c68d1205ced81d78

Comment by Andy Schwerin [ 06/Sep/16 ]

That's not good enough. The primary might have decimal data, say, even though it has since had its FCV set to 3.2. The initial sync should not fail because of this.

Comment by Scott Hernandez (Inactive) [ 06/Sep/16 ]

This seems to be because we start fetching documents (and storing them) before we clone the admin db, to get the upstream setting. Do you have a call-stack from exactly where this happens?

[replication-1] Error fetching oplog during initial sync: InvalidBSON: Cannot use decimal BSON type when the featureCompatibilityVersion is 3.2. See http://dochub.mongodb.org/core/3.4-feature-compatibility.

Initial sync does disable other types of validation (like document validation and index constraints) so if there was a way for initial sync to disable this while it executes that would probably be fine.

Comment by Tess Avitabile (Inactive) [ 06/Sep/16 ]

The secondary validates the incoming BSON. I'm not sure if there is a way to prevent that (or if it is desirable). We could check in rpc/object_check.h whether we are the primary in order to decide which BSON validation version to use, but I'm not sure we'd want to introduce that dependency. If there were a way to construct a Validator<BSONObj> with a particular BSON validation version, we might be able to do that.

Comment by Andy Schwerin [ 06/Sep/16 ]

Shouldn't we just assume that the upstream node was doing the right thing, and accept whatever data it gives us?

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