-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Sharding NYC 2023-02-20, Sharding NYC 2023-03-06, Sharding NYC 2023-03-20, Sharding NYC 2023-04-03, Sharding NYC 2023-04-17
-
161
When the catalog shard feature flag is enabled, a config server will start up with shard components. If the config server is in the latest FCV, it will insert a shardIdentity document locally and consider itself a shard always. To support downgrading to a previous binary, we'll need to remove the shardIdentity document on FCV downgrade, unset ShardingState::enabled(), and ensure the config server can still function properly as a dedicated config server. We'll need to support the inverse when upgrading FCV, ie insert a shardIdentity document and verify the config server functions in both dedicated and catalog shard mode.
Some specific problems to handle:
- The config server will use a ShardServerCatalogCacheLoader (SSCCL) in all FCVs and we should add logic to the SSCCL to become a pure passthrough to its underlying ConfigServerCatalogCacheLoader when FCV is not fully upgraded. This will require gating its behavior on FCV and joining any in progress tasks during FCV upgrade and downgrade.
- Shards don't allow deleting the shardIdentity document, which we'll need to relax for this case.
- ShardingState doesn't support unsetting ShardingState::enabled() currently
- has to be done before
-
SERVER-56579 Enable Feature flag for PM-2290
- Closed
- is depended on by
-
SERVER-74105 Remove catalog shard checks for lower fcv in shard server catalog cache loader
- Closed
- is related to
-
SERVER-75548 Use w:all barrier in transitionToCatalogShard
- Closed
- related to
-
SERVER-71106 Access to Grid members should be protected with isShardingInitialized
- Closed