[SERVER-48906] Investigate whether secondary filtering metadata should handle rollbacks of config.cache.chunks Created: 16/Jun/20  Updated: 27/Oct/23  Resolved: 18/Feb/22

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Randolph Tan Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding EMEA
Participants:

 Description   

When a secondary rolls back changes to config.cache, it keeps its in memory filtering metadata. That means that it could potentially have a filtering metadata version higher than what it actually has. I went through a few scenarios and it looks like it might not invalidate the promises with causal consistency or snapshot reads. A more detailed investigation should be made to decide whether we need to handle rollbacks and document in this ticket if we determined why it is safe to keep it that way.


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