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

The ShardServerCatalogCacheLoader ended up having two different chunks cache

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1.0-rc0
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding EMEA 2021-09-20, Sharding EMEA 2021-10-04
    • Linked BF Score:
      130

      Description

      As part of PM-2384, we introduced two ways of creating the chunks cache on shards: based on the name of the original collection or based on the UUID of that collection.  An invariant of that project, which we don't explicitly check although we might want to do it, is that only one chunks cache exists at the same time. However, this is not always true (from BF-22521):

      1. P1(Primary): it starts a refresh of a certain nss. Despite the fact that in the config server we find that this collection supports long names and the previous info we had about it didn't, we don't actually rename the chunks cache because the epochs are different (which makes a lot of sense).
      2. P1(Primary): The background thread starts removing the entry on config.cache.collection and the config.cache.chunks.nss. A bit after we dropped the chunks cache this node stepsdown. The drop of the chunks cache is rollbacked but not the deletion of the entry on config.cache.collections because it was majority committed.
      3. P2 (New primary): it starts a refresh of the same nss. It doesn't see anything about that name on config.cache.collections since the previous operation was majority committed. maxLoaderVersion is UNSHARDED.
      4. P2 (New primary): it finds valid data on the config server. It creates a task that it is executed by the background thread.
      5. P2 (New primary): the background thread is going to persist the valid info we got from the config server. Since maxLoaderVersion is UNSHARDED we believe that we don't have information about the previous collection so we don't drop config.cache.chunks.nss. A few statements later we create config.cache.chunks.uuid, having two chunk caches for the same name.

      A few questions we have to solve:

        Attachments

          Activity

            People

            Assignee:
            antonio.fuschetto Antonio Fuschetto
            Reporter:
            sergi.mateo-bellido Sergi Mateo Bellido
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: