[SERVER-34675] shard should clear its own CollectionShardingState on dropCollection Created: 25/Apr/18  Updated: 27/Oct/23  Resolved: 04/May/18

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

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

This would eliminate a class of bugs (some which show up in BF's) where the setShardVersion for dropCollection is not sent due to a config failover.



 Comments   
Comment by Esha Maharishi (Inactive) [ 07/May/18 ]

siyuan.zhou, do you mean a SERVER ticket that specifically tracks the crash in renameCollection? (Anywhere we directly use CollectionShardingState::getMetadata(), which includes agg, createIndexes, and update, is susceptible to this bug, though they may not all lead to a crash - they may instead return incorrect results or allow changing an immutable field).

Comment by Siyuan Zhou [ 07/May/18 ]

esha.maharishi, if this is indeed a bug and we are not going to fix it in this ticket, can we at least have a ticket to track it (if not this one), since the bug leads to a crash of secondary and SERVER-34760 only reduces but does not eliminate the likelihood of the crash.

Comment by Esha Maharishi (Inactive) [ 04/May/18 ]

I realized this would not work:

1) config server sends dropCollection to all shards

2) shard drops collection locally

3) shard clears in-memory sharding state for dropped collection

4) shard receives request on collection, which triggers shard to refresh, so shard updates in-memory sharding state

5) config server removes collection from sharding catalog

 

In this case, the shard will still end up with stale in-memory state after the drop.

Closing as Works as Designed (though it is also buggy as designed).

Generated at Thu Feb 08 04:37:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.