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