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

Secondary may not invalidate in-memory routing table cache after primary refresh

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 3.6.3, 3.7.2
    • 3.6.5, 3.7.6
    • Sharding
    • Fully Compatible
    • ALL
    • v3.6
    • Sharding 2018-04-23, Sharding 2018-05-07
    • 25

    Description

      Secondaries have an OpObserver on "config.cache.collections" to invalidate their in-memory routing table cache entry for the namespace whose routing table is being updated, if the oplog entry has field 'lastRefreshedCollectionVersion'.

      Primaries write the 'lastRefreshedCollectionVersion' field when marking the config.cache.collections entry as done refreshing. However, they only write the major/minor versions of the collection version; that is, they do not include the epoch.

      If a sharded collection exists with one chunk (e.g., collectionVersion=(1,0, epoch)), then is dropped, recreated, and re-sharded, but the best-effort setShardVersion for the drop fails, then the refresh after the shardCollection will persist lastRefreshedCollectionVersion=(1,0).

      Since this is no different than the lastRefreshedCollectionVersion already in the config.cache.collections document, the oplog entry for this update will not include the 'lastRefreshedCollectionVersion' field, so the OpObserver on the secondary will not fire.

      Also dianna.hohensee, shouldn't the primary write 'lastRefreshedCollectionVersion' when starting the refresh, so that the secondary invalidates its in-memory cache sooner?

      Attachments

        Activity

          People

            janna.golden@mongodb.com Janna Golden
            esha.maharishi@mongodb.com Esha Maharishi
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: