[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: |
|
||||||||||||
| 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 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 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, |
| 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? Bests, |