Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-73960

Support setFCV transitions when catalog shard feature flag is enabled

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.0.0-rc0
    • 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

            Assignee:
            randolph@mongodb.com Randolph Tan
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: