-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
SERVER-109579 made _shardsvrCoordinateMultiUpdate include mongos's notion of the dbVersion in the MultiUpdateCoordinator's metadata, so that it can be used later when calling _shardsvrBeginMigrationBlockingOperation and _shardsvrEndMigrationBlockingOperation to avoid the issues seen in BF-39044 where these two services can end up running on different shards if a movePrimary commits concurrently.
Even with the changes from SERVER-109579, the MultiUpdateCoordinator will still fall back to the old (incorrect) behavior if running in a multiversion cluster where the originator of _shardsvrCoordinateMultiUpdate does not have the changes from SERVER-109579.
Once we can be sure that all nodes in supported multiversion configurations will contain the changes from SERVER-109579, we should remove this fallback logic and rely on the fact that the dbVersion will always be present in the MultiUpdateCoordinator's metadata. It is likely that the soonest this will happen is in version 10.0 (9.0 is expected to be the first LTS version to include SERVER-109579 at the time of writing).
- is related to
-
SERVER-109579 Fix MultiUpdateCoordinator/MigrationBlockingOperationCoordinator's Participation in Database Versioning
-
- Closed
-