mongodb fails to start after deleting a collection.wt file

562 views
Skip to first unread message

Snehangshu Datta

unread,
Mar 7, 2018, 4:28:36 PM3/7/18
to mongodb-user
We are running mongodb

/mongod --version

db version v3.2.0

git version: 45d947729a0315accb6d4f15a6b06be6d9c19fe7

allocator: tcmalloc

modules: none

build environment:

    distarch: x86_64

    target_arch: x86_64


But while performing housekeeping activity one of the collection file (

collection-96-4240488951662437495.wt

) got deleted.

Now mongodb is not starting as reference to that wt file is present in wiredtiger.wt file. It's a binary file and i doubt removing the trace from that wiredtiger.wt file would corrupt the entire wiredtiger.


DB start error:

2018-03-07T09:15:13.959+0100 E STORAGE  [initandlisten] WiredTiger (-31802) [1520410513:959593][62086:0x7f638661cc80], file:collection-96-4240488951662437495.wt, WT_SESSION.open_cursor: collection-96-4240488951662437495.wt read error: failed to read 4096 bytes at offset 989712384: WT_ERROR: non-specific WiredTiger error
2018-03-07T09:15:13.959+0100 I -        [initandlisten] Invariant failure: ret resulted in status UnknownError -31802: WT_ERROR: non-specific WiredTiger error at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 73




Please suggest.

Kevin Adistambha

unread,
Mar 9, 2018, 1:15:46 AM3/9/18
to mongodb-user

Hi

May I ask what caused the file to be deleted? Was it an intentional deletion?

The dbpath directory contains WiredTiger files that are required for the operation of the database. That is, WiredTiger requires all the files inside the directory to be not moved/deleted/renamed by external means. The error you’re seeing basically means that WiredTiger expects to find the deleted file but couldn’t. At this point, the integrity of the database is compromised, and thus it fails fast and stopped the server to inform you that the database is in an undefined state.

Unfortunately since the database is now in an irrecoverable state, the only thing you can do is to restore from a known good backup. There’s not much any database can do when the files it needs are unexpectedly changing underneath it.

Best regards
Kevin

Reply all
Reply to author
Forward
0 new messages