[SERVER-25361] Deploying a v3.2 cluster with v3.4 config server fails with ShardingTest Created: 29/Jul/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Randolph Tan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DOCS-8140 Document the new balancer control com... Closed
Operating System: ALL
Participants:

 Description   

Setup: v3.2 shards, v3.2 mongos, v3.4 config servers

assert.soon failed, msg:Waited too long for lock balancer to unlock
doassert@src/mongo/shell/assert.js:15:14
assert.soon@src/mongo/shell/assert.js:176:13
sh._waitForDLock@src/mongo/shell/utils_sh.js:251:1
sh.waitForBalancer@src/mongo/shell/utils_sh.js:318:13
sh.stopBalancer@src/mongo/shell/utils_sh.js:175:9
_extendWithShMethods/</self[fn]@src/mongo/shell/shardingtest.js:194:28
_configureCluster@src/mongo/shell/shardingtest.js:208:13
ShardingTest@src/mongo/shell/shardingtest.js:1310:9
@/mnt/hdd/mongo-copy/jstests/multiVersion/new_mongos_old_mongod.js:5:18
@/mnt/hdd/mongo-copy/jstests/multiVersion/new_mongos_old_mongod.js:1:2

This is because the stopBalancer code assumes that if balancerStop command is not found, then it should use the old logic that involves waiting for balancer lock to be freed ( https://github.com/mongodb/mongo/blob/2464cdaf2a2c523ea1c116da60c27ad12e580a09/src/mongo/shell/utils_sh.js#L172). And this will never happen since v3.4 config servers will never release them



 Comments   
Comment by Kaloian Manassiev [ 30/Jul/16 ]

This is a known state, which will be documented and which cloud expects (DOCS-8140 and MMS-3547). The workaround in this case is to have a 3.4 mongos, which will only be used for balancer control.

For the multiverstion tests, we introduced this ShardingTest override, which implements this workaround.

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