-
Type: Sub-task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
v8.0, v7.0, v6.0
-
Cluster Scalability 2024-5-13, Cluster Scalability 2024-5-27, Cluster Scalability 2024-6-10, Cluster Scalability 06/24/24, Cluster Scalability 2024-09-02, Cluster Scalability 2024-10-14, Cluster Scalability 2024-10-28, Cluster Scalability 2024-11-11
Before deciding on a non zero default value for this parameter, test with various values to see what kind of impact we see.
After discussing within the team, we think going with a 30 second default value is appropriate. More reasoning given in the comments.
To do this we could create a temporary test suite where we perform resharding and run with different parameter values. The time in the critical section should be recorded alongside the parameter value so that we can see the impact of the various parameter values.
In addition to this we should also look at the resharding minimum operation duration value and see what the default there is and when the value for it can change (does it change for moveCollections?). If the 30 second delay is encapsulated by the minimum operation duration, then we should be fine to set it to 30 seconds.
- The resharding minimum operation duration is exclusive to the the 30 second delay we would like to add.
- causes
-
SERVER-98451 Do not set reshardingDelayBeforeRemainingOperationTimeQueryMillis when launching patch versions where this parameter doesn't exist
- In Code Review
- is depended on by
-
SERVER-95610 Update version check for reshardingDelayBeforeRemainingOperationTimeQueryMillis in servers.js
- Closed