[SERVER-28796] remove check in CollectionShardingState::onDropCollection that prevents 'config.version' from being dropped Created: 13/Apr/17  Updated: 27/Oct/23  Resolved: 01/Apr/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.4.3, 3.5.5
Fix Version/s: None

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

Issue Links:
Depends
is depended on by TOOLS-1629 can not mongorestore a sharded cluste... Closed
Related
Assigned Teams:
Sharding EMEA
Sprint: Sharding 2017-05-29
Participants:

 Comments   
Comment by Kaloian Manassiev [ 01/Apr/21 ]

Dropping any of the config collections on a running cluster is never safe so we will not start allowing it. The workaround would be to start the config server in a standalone mode (without the --configsvr parameter) and restore manually the config collections.

Comment by Animesh [ 26/Dec/18 ]

Hi Mongo Team,

Even I hit the same issue when restoring config server in v3.4
Is there a work-around for restoring config servers from a mongodump file until this issue is fixed ?

We have been struggling to migrate to v3.4 from v3.2 but this issue is a critical one we need to figure out before we make the jump to v3.4

Comment by Gianluca De Cicco [ 29/Jan/18 ]

Hello,
I got in this issue also in version 3.6.2.

I tried as workaround to restore the first time with the flag "--drop" and after the error, I've executed again without the flag.

Everything seems working, but based on your deeper knowledge, there might be some other problem related to this workaround?

Thanks,
Gianluca

Comment by Esha Maharishi (Inactive) [ 14/Apr/17 ]

Hi csjpeter,

It's true that the running config server will have generated a config.version document.

However, if the intent is to restore the entire config server through mongorestore, it is correct to replace the config.version document with the one in the backup.

Note that this means the shards should also be restored from a full backup, so that the clusterId field in each shard's shardIdentity document matches the version field in the config's version document.

(The check was there to prevent users from accidentally deleting the version document).

Comment by Császár Péter [ 14/Apr/17 ]

Hello Reporter,

Will there be a check if the dumped version is compatible with the one to overwrite?
What will happen in case of incompatibility?
I merely guess that the check is/were there to avoid restoring of old (incompatible) dumps on newer mongo setup.

Bests,
Peter

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