[SERVER-57496] Proactively evict cached entries after drop database/collection Created: 07/Jun/21 Updated: 29/Oct/23 Resolved: 29/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 5.1 Required |
| Fix Version/s: | 5.0.2, 5.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | Simon Gratzer (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-1965-Cleanup | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v5.0
|
||||
| Sprint: | Sharding EMEA 2021-06-14, Sharding EMEA 2021-06-28 | ||||
| Participants: | |||||
| Description |
|
Both drop database and drop collection on sharded cluster currently only invalidate the information on the DatabaseShardingState and the CollectionShardingRuntime after the database/collection have been dropped. The rename collection operation also cleans up the CollectionShardingRuntime. This is enough to ensure that subsequent requests will be causal consistent with the DDL operation. In order to free-up some memory, we should also proactively evict the cached entries for the dropped db/coll or renamed coll in the catalog cache. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 28/Jun/21 ] |
|
Author: {'name': 'Simon Graetzer', 'email': 'simon.gratzer@mongodb.com'}Message: |