Invert order of shards receiving drop collection participant command

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 5.2.0, 5.0.4, 5.1.0-rc3
    • Affects Version/s: 5.0.3, 5.1.0-rc2
    • Component/s: Sharding
    • None
    • Fully Compatible
    • v5.1, v5.0
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Both drop database and drop collection coordinators are sending the drop participant command first to the primary shard and then to the others.

      As a result, the current behavior permits to see the following change stream events (thanks max.hirschhorn for pointing that out):

      1. drop change event from primary shard
      2. insert change event from primary shard (unsharded collection implicitly recreated)
      3. drop change event from other shard

      It would be difficult for a client to know whether the insert (2) happened during or after the drop. Inverting the order would prevent such interleaving of events.

              Assignee:
              Pierlauro Sciarelli
              Reporter:
              Pierlauro Sciarelli
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: