[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:
Backports
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: SERVER-57496 Proactively evict cached entries after drop database/collection
Branch: master
https://github.com/mongodb/mongo/commit/1a78afe4e8a97d21e99f39504bd2ef451f1d7fa7

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