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

_configsvrReshardCollection may return without having waited for unsetting "reshardingFields" to replicate to majority

    • Fully Compatible
    • ALL
    • v5.2, v5.1, v5.0
    • Sharding 2021-12-27, Sharding 2022-01-10
    • 2

      The _configsvrReshardCollection command waits on the completion future returned by the ReshardingCoordinator. This completion future becomes ready after the local replica set transaction to delete the config.reshardingOperations document and unset the reshardingFields from the config.collections entry commits with w:majority. (Note that SERVER-61444 may change it to be w:1 and move when the wait for majority happens.)

      If there is no in-progress ReshardingCoordinator and the desired shard key pattern already matches the current shard key pattern, then the _configsvrReshardCollection command returns without waiting on a completion future. This read of the config.collections entry to check the current shard key pattern happens with read concern level "local" and may therefore reflect changes which could be rolled back.

      The impact here is low because the "effect" which can be rolled back is only the ReshardingCoordinator's removal of the reshardingFields from the config.collections entry. It is still guaranteed that the update to the shard key pattern in the config.collections has already been majority-committed.

      repl::ReplClientInfo::forClient(opCtx->getClient()).setLastOpToSystemLastOpTime(opCtx);
      

      can be used to ensure ServiceEntryPointMongod::Hooks::waitForWriteConcern() will wait for write concern.

            Assignee:
            brett.nawrocki@mongodb.com Brett Nawrocki
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: