[SERVER-34342] FCV is "3.2" for new 3.4 replica set with clusterMode: shardsvr Created: 05/Apr/18  Updated: 27/Oct/23  Resolved: 06/Apr/18

Status: Closed
Project: Core Server
Component/s: Sharding, Upgrade/Downgrade
Affects Version/s: 3.4.14
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Spencer Brown Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to DOCS-11551 New 3.4 replica set with shardsvr opt... Closed
Operating System: ALL
Steps To Reproduce:
  • Create a 3.4.14 single member replica set with sharding.clusterRole: shardsvr, with no data so it's brand new, for example:

processManagement:
  fork: true
 
storage:
  dbPath: data/m1
  journal:
    enabled: true
 
systemLog:
  destination: file
  path: data/m1.log
 
replication:
  replSetName: rs
 
sharding:
  clusterRole: shardsvr

  • Connect with mongo shell and rs.initiate()
  • Run db.adminCommand( {getParameter: 1, featureCompatibilityVersion: 1 }

    )

output is:

{ "featureCompatibilityVersion" : "3.2", "ok" : 1 }

Expected output is that the FCV is "3.4" as this is a new replica set.

Participants:

 Description   

Starting a new single member 3.4.14 replica set with no data, and the configuration includes sharding.clusterRole: shardsvr, causes the featureCompatibilityVersion to be reported as "3.2".

Removing the sharding.clusterRole: shardsvr option and restarting the mongod does not change the FCV to "3.4".

However starting a new single member replica set (no data) without shardsvr works correctly, showing FCV of "3.4", and restarting it with shardsvr also still shows FCV of "3.4".

Note that there is no FCV document in admin.system.version during all this. Running setFeatureCompatibilityVersion: "3.4" works to set the FCV to 3.4, so this issue is only about what FCV is assumed when you start a brand new replica set.



 Comments   
Comment by Eric Milkie [ 06/Apr/18 ]

The behavior as described is expected.

Comment by Spencer Brown [ 06/Apr/18 ]

Indeed, testing shows that once the new 3.4.14 replica set with sharding.clusterRole: shardsvr is added to the sharded cluster, the FCV becomes "3.4", and a FCV document has been added to admin.system.version.

Comment by Andy Schwerin [ 05/Apr/18 ]

Nodes started with shardsvr in version N must assume fcv N-1 until they are added to the a cluster, in case that cluster is still at fcv N-1. Adding the shard to an fcv N cluster should cause the shard to upgrade to fcv N as well.

Comment by Eric Milkie [ 05/Apr/18 ]

I think you have to finish setting up sharding before you start looking at FCV reporting.
If you enable sharding, does that change FCV?

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