Uploaded image for project: 'MongoDB Database Tools'
  1. MongoDB Database Tools
  2. TOOLS-1629

can not mongorestore a sharded cluster with mongo 3.4



    • Type: New Feature
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Works as Designed
    • Affects Version/s: 3.4.2
    • Fix Version/s: None
    • Component/s: mongorestore
    • Labels:
    • Environment:
      The bug is not OS nor hardware dependent.
      It happens for sharded cluster restore only.
    • Backport Requested:


      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.


          Issue Links



              esha.maharishi Esha Maharishi
              csjpeter Császár Péter
              0 Vote for this issue
              8 Start watching this issue