-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
ClusterScalability 8Jun-22June
-
10
-
None
-
None
-
None
-
None
-
None
-
None
-
None
We recently made a change (SERVER-123568) for v9.0 to pin the FCV version the resharding uses during its lifetime. This means that binaries in v9.0 running resharding will never experience mixed fcv among the participants. However, this also creates a new kind of behavior where the resharding could be using a code path that is at a different version from the rest of the system. Particularly, when it pins the version to v8.0 while a setFCV upgrade is happening. This could result in resharding using the legacy shard version refresh while the system is now in the shard authoritative no refresh mode. We should test all these scenarios (some already exist today like pinned 9.0 + fcv 9.0).
| Pinned Version | FCV Version |
| 8.0 | 8.0 |
| 8.0 | 9.0 |
| 9.0 | 8.0 |
- is duplicated by
-
SERVER-125854 Multiversion and Upgrade/Downgrade Testing
-
- Closed
-
- is related to
-
SERVER-123568 Use VersionContext to pin resharding coordinator FCV across its lifetime
-
- Closed
-
- related to
-
SERVER-128025 setFCV should abort resharding coordinators before draining in config shard topology
-
- Closed
-