-
Type: New Feature
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.4.2
-
Component/s: mongorestore
-
None
-
Environment:The bug is not OS nor hardware dependent.
It happens for sharded cluster restore only.
-
v3.4
When I tried to restore a sharded cluster by a command like this:
nc -dl 9876 | /usr//bin/mongorestore --host localhost --port 27019 --username backup --password xxxxxx --authenticationDatabase admin --drop --oplogReplay --gzip --archive
I got the error message:
Failed: config.version: error dropping collection: cannot drop config.version document while in --configsvr mode
Trial 1
--------
I tried to restart the config replica set as shard data replicaset, but I it failed to start an I found this error in the mongo log file:
{{2017-01-12T17:21:44.033+0000 W SHARDING [initandlisten] Started with --shardsvr, but no shardIdentity document was found on disk in admin.system.version. This most likely
means this server has not yet been added to a sharded cluster.}}
I tried to restart the config replicaset as simple (non shard) replicaset. That failed with this:
E REPL [replExecDBWorker-0] Locally stored replica set configuration is invalid; See http://www.mongodb.org/dochub/core/recover-replica-set-from-invalid-config for information on how to recover from this. Got "BadValue: Nodes being used for config servers must be started with the --configsvr flag"
Trial 2
--------
I tried to add --nsExclude config.version to the mongorestore command and I got:
2017-01-11T19:26:41.675+0000 Failed: cannot use --oplogReplay with excludes specified
Trial 3
--------
I also tried to make backup without the config.version collection:
/usr//bin/mongodump -h localhost:27017 --excludeCollection "config.version" --oplog --gzip --archive --username backup --password xxxxxx --authenticationDatabase admin
I got this:
Failed: bad option: --db is required when --excludeCollection is specified
So lets specify --db as well:
{{/usr//bin/mongodump -h localhost:27019 --oplog --gzip --archive --username backu
p --password xxxxxx --authenticationDatabase admin --db config --excludeCollectionsWithPrefix db.config.version}}
The result is:
2017-01-12T09:36:57.669+0000 Failed: bad option: --oplog mode only supported on full dumps
--------------------------------
I am running out of ideas. Is it working at all to restore a sharded cluster's config replicaset with mongodb 3.4? With mongodb 3.2 the restore worked even with config replicaset.
- depends on
-
SERVER-28796 remove check in CollectionShardingState::onDropCollection that prevents 'config.version' from being dropped
- Closed