-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
1
While working on SERVER-95169 upgrading the config server would cause it to hang if it was configured to use multiple nodes. This was hard to debug since i followed the syntax that some jsTests use to specify the amount of nodes in the config server, config: {nodes: 1}{}, but this syntax is incorrect. This is because shardingtest.js takes into account 3 different scenarios:
1. config: X where it will create the config server with X amount of nodes
2. config: {c0: {...options}, c1: {...options}, ... , cX: {...options} where it will create the config server with X amount of nodes, each with whatever options got passed
3. config: [{...options}, {...options}, ... , {...options}] where it will create the config server with the array-length amount of nodes, each with whatever options got passed
1 and 3 work well, but 2 doesn't enforce the use of c0, c1, cX naming, it simply increments numConfigs based on how many objects there are, and later on it will try to get the node options by looking up nodes named cX.
This means that using config: {nodes: X} is wrong because it will not create an X amount of nodes in the config server (except when X == 1 since there's only a single object, which is why this went unnoticed). Furthermore, something like config: {a0: {...options}} is incorrect since, even though it gets the right amount of nodes, the options will not get passed onto it, as it is not of the name cX. This is easily spotted when using something like c0: {verbose: 5} vs a0: {verbose: 0} and looking at the difference in the logs.
The correct behavior should also be specified in shardingtest_guide.js.
- is related to
-
SERVER-95169 Add multiversion query test which stresses sharded scenarios
- Closed
- related to
-
SERVER-97372 Add multiversion testing for multiple-node config servers
- Needs Scheduling