[SERVER-66006] Ensure that the CRUD events use the new shard key only after a reshardCollection event is generated Created: 27/Apr/22 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Arun Banala | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Execution
|
||||
| Participants: | |||||
| Description |
|
Currently during the reshardCollection operation, the concurrent write operations on the collection being resharded can succeed during this phase execution. The distributed lock won't exclude new incoming writes on the collection. Since the change stream returns the events ordered on the clusterTime, there could be some writes which start using the new shard key value before logging the reshardCollection operation in the oplog. This would result in us reporting write events with new shard key value (as documentKey), before reporting the reshardCollection event. |