[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:

  • Node A is primary and refreshes, discovering shard version X
  • Step-down
  • Node B becomes primary and refreshes, discovering shard version X - 1 because reading from the (stale) nearest CSRS node

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.

Generated at Thu Feb 08 05:54:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.