Mongodb 3.0.7 and error 14

Ops and Admin
1

Our monogdb 3.0.7 database appears to have crashed. When starting the database, I get an Error 14. Looking online, most people suggested looking at date/time and permissions. Neither of those are the issue. I do not have a backup of the database to restore. What can I do get the database operational?

I have set the database aside and was able to initialize a new one. So the mongo binaries are ok.
I have tried combining old index and collection files with a new database structure which did not work (still trying to learn about the database structure).
Files “WiredTiger.turtle” and “WiredTiger.wt” are not zero bytes.
I have removed “mongod.lock” and still get the Error 14.
I tried pointing mongoDB 3.2.22 at the database (hoping an upgrade would fix it) but still got the same Error 14 message.

I’ve seen a few recovery articles, but I am still hoping there is an alternative.

Brian

2

Error Code 14 is somewhat generic.

Returned by MongoDB applications which encounter an unrecoverable error, an uncaught exception or uncaught signal. The system exits without performing a clean shutdown.

Post your full error message here this may assist in diagnosis.

2 Likes
3 
2020-12-01T11:24:06.218-0500 I CONTROL  [main] ***** SERVER RESTARTED *****
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] MongoDB starting : pid=10875 port=27017 dbpath=/Volumes/Pathsrv1Data2/MongoDb 64-bit host=pathsrv1.yalepath.org
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] db version v3.2.22
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] git version: 105acca0d443f9a47c1a5bd608fd7133840a58dd
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] allocator: system
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] modules: none
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] build environment:
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten]     distarch: x86_64
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten]     target_arch: x86_64
2020-12-01T11:24:06.226-0500 I CONTROL  [initandlisten] options: { config: "/usr/local/etc/mongod.conf", net: { bindIp: "pathsrv1.yalepath.org,10.48.106.44" }, processManagement: { fork: true }, security: { authorization: "enabled" }, storage: { dbPath: "/Volumes/Pathsrv1Data2/MongoDb", engine: "wiredTiger" }, systemLog: { destination: "file", logAppend: true, path: "/usr/local/var/log/mongodb/mongo.log" } }
2020-12-01T11:24:06.228-0500 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=9G,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),verbose=(recovery_progress),
2020-12-01T11:24:06.231-0500 E STORAGE  [initandlisten] WiredTiger (22) [1606839846:231197][10875:0x10d8e6dc0], file:WiredTiger.wt, connection: live.avail: merge range 4096-16384 overlaps with existing range 12288-16384: Invalid argument
2020-12-01T11:24:06.231-0500 E STORAGE  [initandlisten] WiredTiger (-31804) [1606839846:231304][10875:0x10d8e6dc0], file:WiredTiger.wt, connection: the process must exit and restart: WT_PANIC: WiredTiger library panic
2020-12-01T11:24:06.231-0500 I -        [initandlisten] Fatal Assertion 28558
2020-12-01T11:24:06.231-0500 I -        [initandlisten] 

***aborting after fassert() failure
4

I’d recommend you stay with the version that last successfully ran this database, also try the last version of the 3.0 series.

I think you are into a recover from backup scenario, but you could try a --repair startup.

You should upgrade to a current supported version as soon as you can. This version is well out of support and updates.

1 Like
5

I tried using --repair with v3.0.7 and got the same Error 14.
Yes, I would like to upgrade after I get out of this mess.

Any other things I can try to get it running?
If not, any documentation you can suggest to recover the existing database files?

Thanks, Brian

6

I’m not aware of any recovery method of the existing file. You’re recovering from backup at this point(assuming standalone mongodb).