[SERVER-60923] Clear cached database information asyncronously after dropping it Created: 22/Oct/21  Updated: 27/Oct/23  Resolved: 22/Oct/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 5.0.3, 5.1.0-rc1
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Allison Easton
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding EMEA 2021-11-01
Participants:

 Description   

Currently as part of the drop database coordinator flow, we broadcast _flushDatabaseCacheUpdates  command with majority write concern to all shards and we wait synchronously for its execution.
The only purpose of this call is to flush the cached entries of the dropped database from all the nodes in the cluster to reclaim memory. So it is not strictly required.
For this reason I think we should:
 - stop using the majority write concern
 - use fireAndForget to asynchronously schedule the command execution on all the shards and not block this coordinator.



 Comments   
Comment by Tommaso Tocci [ 22/Oct/21 ]

kaloian.manassiev mentioned that this approach would potentially leave garbage entries in config.cache.databases. Even though this wouldn't be a correctness issue we decided that the dropDatabase should ensure no garbage is left behind even if this would result in a slower operation.
Thus I'm closing this ticket.

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