I believe my MongoDB did not have a clean shutdown. I am able to restart it in a new location which doesn't have all of my collections. If I try to repair or start it in the old location, it gives the following error:

[ec2-user@ip-172-31-30-192 tmp]$ mongod --repair --dbpath /data

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] MongoDB starting : pid=31865 port=27017 dbpath=/data 64-bit host=ip-172-31-30-192

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] db version v3.2.16

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] git version: 056bf45128114e44c5358c7a8776fb582363e094

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.0-fips 29 Mar 2010

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] allocator: tcmalloc

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] modules: none

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] build environment:

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] distmod: amazon

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] distarch: x86_64

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] target_arch: x86_64

2017-08-20T16:20:30.951+0000 I CONTROL [initandlisten] options: { repair: true, storage: { dbPath: "/data" }

} 2017-08-20T16:20:30.972+0000 I - [initandlisten] Detected data files in /data created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.

2017-08-20T16:20:30.972+0000 I STORAGE [initandlisten] Detected WT journal files. Running recovery from last checkpoint.

2017-08-20T16:20:30.972+0000 I STORAGE [initandlisten] journal to nojournal transition config: create,cache_size=17G,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),

2017-08-20T16:20:30.981+0000 E STORAGE [initandlisten] WiredTiger (-31802) [1503246030:981472][31865:0x7f6ad1d9fd80], file:WiredTiger.wt, connection: unable to read root page from file:WiredTiger.wt: WT_ERROR: non-specific WiredTiger error

2017-08-20T16:20:30.981+0000 E STORAGE [initandlisten] WiredTiger (0) [1503246030:981530][31865:0x7f6ad1d9fd80], file:WiredTiger.wt, connection: WiredTiger has failed to open its metadata

2017-08-20T16:20:30.981+0000 E STORAGE [initandlisten] WiredTiger (0) [1503246030:981548][31865:0x7f6ad1d9fd80], file:WiredTiger.wt, connection: This may be due to the database files being encrypted, being from an older version or due to corruption on disk

2017-08-20T16:20:30.981+0000 E STORAGE [initandlisten] WiredTiger (0) [1503246030:981564][31865:0x7f6ad1d9fd80], file:WiredTiger.wt, connection: You should confirm that you have opened the database with the correct options including all encryption and compression options

2017-08-20T16:20:30.981+0000 I - [initandlisten] Assertion: 28718:-31802: WT_ERROR: non-specific WiredTiger error

2017-08-20T16:20:30.982+0000 I STORAGE [initandlisten] exception in initAndListen: 28718 -31802: WT_ERROR: non-specific WiredTiger error, terminating

2017-08-20T16:20:30.982+0000 I CONTROL [initandlisten] dbexit: rc: 100

Is there a way to fix my wiredtiger.wt file or move my collections and indexes from the old location into the new location?

  • You can try with wt command. This can be found from wiredtiger package. But I'm pretty sure that fixing is not possible this case.
    – JJussi
    Aug 21 '17 at 4:32
  • What is the wt command? So you dont think there is a way to recover the database? The wiredtiger.wt file is small 164KB.
    – Jay Gupta
    Aug 21 '17 at 13:56
  • source.wiredtiger.com/2.6.0/command_line.html but at least at ubutuntu you can install it apt install wiredtiger
    – JJussi
    Aug 22 '17 at 3:22

There's now an official repair option that worked for me after a sudden computer shutdown https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/

  1. Create a backup copy of the data files in the --dbpath
  2. Start mongod with --repair

mongod --dbpath /data/db --repair

Upon completion, the dbpath should contain the repaired data files and an empty mongod.lock

The collections were repaired without data loss.


Have you seen this I have used it in the past for this issue:



As per log the mention repair command --dbpath is only /data. I think OP is doing mistake here. Because as per MongoDB BOL documentation here the default --dbpath should be /data/db on Linux and macOS, \data\db on Windows.

Default: /data/db on Linux and macOS, \data\db on Windows

The directory where the mongod instance stores its data.

If you installed MongoDB using a package management system, check the /etc/mongod.conf file provided by your packages to see the directory is specified.

Even as per OP mention log , the MongoDB version is v3.2.16.

As per @David Hows MongoDB jira blog here.

You need the entire dbpath as it was when you took the backup. MongoDB with WiredTiger performs consistency checks on boot by attempting to open each collection within the system. The list of collections is stored in both the WiredTiger.wt and _mdb_catalog.wt files, which also have integrity checking. If any one of the collections in the system at time of backup is not present or fails initial checksum validation then your instance will abort during boot.

If you wish to restore a single collection, then you would need to first restore the whole dbpath into a stand-alone instance, then use database commands to drop the unwanted collections.

For further your ref here and here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.