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

Whole-DB or whole-cluster change streams may not provide a total ordering if resumed after a drop

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Query 2018-05-21, Query 2018-06-04

      Description

      This is a more general case than the one described in SERVER-34702, but it has a known solution.

      Consider the following sequence of events:

      • A whole-db or whole-cluster change stream is opened and returns some change stream entries for updates. These notifications include the shard key.
      • Two operations happen on different shards at the same cluster time. At least one of these operations is an insert.
      • A collection is dropped.
      • The change stream is resumed using the update event's resume token.
      • When processing the insert notification which has the same cluster time as another change, the change stream machinery does not know what the shard key is for the collection, so only includes the _id in the resume token.
      • This change will now have a practically arbitrary order with the other change at the same cluster time. If that change was also an insert, they will be compared by _id. It's possible that the two inserts have the same _id and the same cluster time.

      One suggested approach for this problem is to remember the shard key that was given to us in the resume token when we resume, allowing us to populate the shard key for the insert entry. This will solve this scenario, but will not solve the scenarios described in SERVER-34702.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              nicholas.zolnierz Nicholas Zolnierz
              Reporter:
              charlie.swanson Charlie Swanson
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: