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

Resharding can fail with NamespaceNotSharded if recipient primary fails over before creating temporary resharding collection

    • Fully Compatible
    • ALL
    • v5.2, v5.1, v5.0
    • Sharding 2022-01-10, Sharding 2022-01-24
    • 30
    • 3

      ShardServerOpObserver::onCreateCollection() sets the filter metadata for the collection as unsharded if the collection isn't already known to be sharded. This behavior isn't something which can be changed without significant work from Sharding EMEA, although it would probably be better to leave the filtering metadata as unknown.

      The following scenario can therefore lead the recipient shard primary to wrongly believe the temporary resharding collection is unsharded and for it to throw a NamespaceNotSharded exception from assertCanExtractShardKeyFromDocs().

      1. Recipient shard primary in term=1 is told by coordinator to refresh on the temporary resharding collection. At this point the recipient shard primary knows the temporary resharding collection is sharded.
      2. Recipient shard primary in term=1 constructs a RecipientStateMachine and waits for all donor shards to be prepared to donate.
      3. Recipient shard primary in term=1 is told by coordinator all donor shards are prepared to donate.
      4. Recipient shard primary in term=1 is transitions from RecipientStateEnum::kAwaitingFetchTimestamp to RecipientStateEnum::kCreatingCollection.
      5. An election occurs and there's a new recipient shard primary in term=2.
      6. Recipient shard primary in term=2 clears the filtering metadata for the temporary resharding collection on step-up.
      7. Recipient shard primary in term=2 creates the temporary resharding collection. ShardServerOpObserver::onCreateCollection() causes the recipient shard primary to set the filtering metadata for the temporary resharding collection as unsharded.

      This happens because the recipient shard primary in term=2 resumes without being guaranteed it has itself refreshed from the config server and set the filter metadata for the temporary resharding collection as sharded. One solution is to have the recipient shard primary clear the filtering metadata for the temporary resharding collection after creating it so that resharding's collection cloning and resharding's oplog application can simply refresh to set it as sharded.

            Assignee:
            matt.boros@mongodb.com Matt Boros
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: