[SERVER-34705] Whole-DB or whole-cluster change streams may not provide a total ordering if resumed after a drop Created: 26/Apr/18  Updated: 29/Oct/23  Resolved: 29/May/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: 4.0.0-rc2, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Nicholas Zolnierz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-34702 Whole-DB or whole-cluster change stre... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Sprint: Query 2018-05-21, Query 2018-06-04
Participants:

 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.



 Comments   
Comment by Githook User [ 04/Jun/18 ]

Author:

{'username': 'nzolnierzmdb', 'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com'}

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

(cherry picked from commit 55f4dbf94a1cce9d8642af9bba9ac4cc77627293)
Branch: v4.0
https://github.com/mongodb/mongo/commit/753cedd024b9f4fe1a83632db792f29d3a7e4454

Comment by Githook User [ 29/May/18 ]

Author:

{'username': 'nzolnierzmdb', 'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com'}

Message: SERVER-34705: Whole-DB or whole-cluster change streams may not provide a total ordering if resumed after a drop
Branch: master
https://github.com/mongodb/mongo/commit/55f4dbf94a1cce9d8642af9bba9ac4cc77627293

Generated at Thu Feb 08 04:37:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.