[SERVER-22648] move existing removeShard procedure into _configsvrRemoveShard Created: 16/Feb/16  Updated: 26/Oct/23

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

Type: Task Priority: Major - P3
Reporter: Crystal Horn Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: AdiZ, PM-108, oldshardingemea
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Catalog and Routing
Sprint: Sharding 15 (06/03/16), Sharding 16 (06/24/16), Sharding 17 (07/15/16)
Participants:

 Comments   
Comment by Esha Maharishi (Inactive) [ 15/Jul/16 ]

This is necessary mainly to cancel pending upsertShardIdentityForAddShard tasks on the primary config.

If we did not do this, those tasks would continue to reschedule themselves on the thread pool executor indefinitely, and could only be stopped be restarting the primary config.

Comment by Esha Maharishi (Inactive) [ 29/Jun/16 ]

Note: We decided to change removeShard to delete the shardIdentity document (option 2).

Comment by Spencer Brody (Inactive) [ 10/May/16 ]

As far as I can tell the options here are to

  1. Do nothing. Removing a shard will still work, but you won't be able to re-add that shard to a different sharded cluster or with a different shard name (unless you manually restart the shard without --shardsvr, remove the shardIdentity document, then restart it with --shardsvr again). Should still be possible to re-add the shard to the same cluster so long as it has the same shard name.
  2. Add a step to the removeShard procedure where the shardIdentity document is removed.
    1. When the shardIdentity document is removed, clear out all the in-memory sharding state on the mongod. This would allow this shard to be added to a new cluster or re-added to the same cluster with a different shard name without restarting any processes.
    2. Don't clear the in-memory state when the shardIdentity document is removed. This would mean that in order to add this shard to a different cluster or with a different name all mongod processes in the shard would need to be bounced.

I'm kind of leaning towards option #1, which also happens to be the least amount of work. I'm not sure we really buy much by being able to re-add a previously removed shard.

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