[SERVER-62271] Checkpoint the vector clock when discovering new shard versions Created: 24/Dec/21 Updated: 26/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | PM-2144-Milestone-0, oldshardingemea | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Catalog and Routing
|
| Sprint: | Sharding EMEA 2022-02-21, Sharding EMEA 2022-03-07, Sharding EMEA 2022-03-21, Sharding EMEA 2022-04-04, Sharding EMEA 2022-04-18, Sharding EMEA 2022-05-02 |
| Participants: | |
| Story Points: | 1.5 |
| Description |
|
Persisting the vector clock before setting the filtering metadata discovered after refreshing ensures causal consistency in the following scenario:
In order to not block the shard for too long of a time, the checkpoint must be done only with local write concern. |
| Comments |
| Comment by Jordi Serra Torrens [ 29/Jun/23 ] |
|
Moved this ticket to PM-2948 since this will no longer be needed once shards are authoritative for what they own. |