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

ShardingCatalogManager::assignKeyRangeToZone() reads stale version of CollectionType while running locally on config server primary

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 5.1.0, 5.0.4
    • 5.2.0, 5.1.2, 5.0.6
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • v5.1, v5.0
    • Execution Team 2021-11-29
    • 152

    Description

      The changes from 21f26eb as part of SERVER-57566 added a usage of RSLocalClient::queryOnce(kMajorityReadConcern) when RSLocalClient::queryOnce(kLocalReadConcern) was intended. ShardingCatalogClient::getCollection() defaults to use kMajorityReadConcern when the repl::ReadConcernLevel is omitted.

      This issue was discovered during SERVER-59831 because it caused a later write using the same OperationContext to still be using kMajorityCommitted as its ReadSource and for the later write not to see the effects of an earlier write from secondary batch application.

      try {
          const auto& coll = Grid::get(opCtx)->catalogClient()->getCollection(opCtx, nss);
          const auto& timeseriesField = coll.getTimeseriesFields();
          if (timeseriesField) {
              uassertStatusOK(
                  checkForTimeseriesTimeFieldKeyRange(actualRange, timeseriesField->getTimeField()));
          }
      } catch (const ExceptionFor<ErrorCodes::NamespaceNotFound>&) {
          // collection doesn't exist or not sharded, skip range check for time-series collection.
      }
      

      Attachments

        Issue Links

          Activity

            People

              yuhong.zhang@mongodb.com Yuhong Zhang
              max.hirschhorn@mongodb.com Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: