0
votes

There are a few SO questions tangentially related. But none quite as simple as this solution:

I was running a standalone mongodb single instance on Mac OSX for development purposes.

Mac crashed...

On restarting the mongo, I could see Mongo trying to recover (mongod.lock file detected) and restart.

(In the past, I would just blow away all of my local dev database folder and start over. Kind of a bummer. But this time I decided to dig a little deeper.)

The key thing to note in the console output is that it found "files created by the 'mmapv1' storage engine, so setting the active storage engine to 'mmapv1'." Essentially overriding the config setting for wiredTiger.

:-O

My console (edited for brevity):

db version v3.2.10
git version: 79d9b3ab5ce20f51c272b4411202710a082d0317
OpenSSL version: OpenSSL 1.0.2l  25 May 2017
allocator: system
modules: none
build environment:
    distarch: x86_64
    target_arch: x86_64
options: { ...storage: { dbPath: "/Users/jon/databases/mongodb", directoryPerDB: true, journal: { enabled: true }, wiredTiger: { engineConfig: { cacheSizeGB: 4 } } }, ... }
Detected data files in /Users/jon/databases/mongodb created by the 'mmapv1' storage engine, so setting the active storage engine to 'mmapv1'.
Detected unclean shutdown - /Users/jon/databases/mongodb/mongod.lock is not empty.
journal dir=/Users/jon/databases/mongodb/journal
recover begin
info no lsn file in journal/ directory
recover lsn: 0
recover /Users/jon/databases/mongodb/journal/j._0
recover cleaning up
removeJournalFiles
recover done
Durability thread started
Journal writer thread started

But I received this warning:

Detected configuration for non-active storage engine wiredTiger when current storage engine is mmapv1

And it ends badly:

***aborting after invariant() failure
...
-----  END BACKTRACE  -----
Abort trap: 6
1

1 Answers

0
votes

A SOLUTION

Admittedly, this is a sticky situation to find yourself in.

I backed up my entire local folder, just so I could try other approaches...

I looked over the directory where I store the database files and purged older folders that truly were not needed. But this may not have been the reason things worked.

I also ran a repair (it could require removal of the journal file depending on your situation):

mongod --dbpath /Users/jon/databases/mongodb --repair

Upon restarting mongo, everything was back to normal.