During shard split or merge, creating a new change stream after the block timestamp might skip events on the recipient

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • QE 2023-05-15
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      • Donor blocks writes  for tenant1 at TS(100).
      • New $changeStream aggregate comes in, initializes start time to current clusterTime, TS(300), returns empty batch with PBRT=TS(300)
      • Migration commits. We advance the recipient clock to be at least  blockTS , here is TS(100).
      • On Recipient, new writes starts to come in  and they writes at TS(200).
      • Client issues CS getMore, gets ResumeTenantChangeStream, driver retries
      • CS cursor resumes from the last token it saw, i.e. the PBRT at TS(300)
      • Change stream resumes on recipient but skips all events that occurred between TS(100) and TS(300)

            Assignee:
            Mickey Winters
            Reporter:
            Mickey Winters
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: