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

Strict Epoch comparison

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.7.2
    • Affects Version/s: 2.5.2
    • Component/s: Sharding
    • Labels:
      None
    • ALL

      Turn on strict enforcement of OID - OID(000...) is no longer a "wildcard" that matches everything. This probably means we need to double-check (again) that the cluster's OIDs are well-formed. This is in preparation for enforcing the invariant that collections of different incarnations are not compatible with each other. The epoch of OID(000...) will also be changed to represent a dropped/unversioned/unsharded collection.

      Background:
      The epoch portion (with type OID) of the shard/collection version in a sharded collection is used to differentiate between different incarnations of collections with the same name. For example, given the events:

      1. shard test.user
      2. drop test.user
      3. shard test.user

      The test.user collection in #1 & #3 will have different epochs.

      List of bugs that are known to fail existing tests when the strict comparison is enforced (ie., these needs to be fixed first before we can flip the switch):
      1. Inside setShardVersion there is a short circuit logic for comparing zero versions, totally ignoring the epoch component here.
      2. There is a bug inside ChunkManager where it sets the epoch to zero if it cannot find a chunk for a shard.

      List of suspicious use of OID(000...) but does not cause existing tests to fail:
      1. Inside setShardVersion, here.

            Assignee:
            randolph@mongodb.com Randolph Tan
            Reporter:
            randolph@mongodb.com Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: