2 / 3
Sep 2024

Hi,

I received a copy of a whole Mongo database to analyse. This one is based on Mongodb 6.x.
Starting the server with this db don’t work. There seems to need a repair first.
While doing the repair I get this error message on Windows, Debian or Ubuntu (using all version of mongodb 6.0.x):

:"Locker status","attr":{"id":1,"requests":[{"key":"{2305843009213693952: Global, 0}","status":"granted","mode":"IS"},{"key":"{: Global, 1}","status":"granted","mode":"IX"},{"key":"{numbersxxxxx+1: Global, 2}","status":"granted","mode":"IX"},{"key":"numbersxxxxx+2: Global, 3}","status":"granted","mode":"X"}]}} {"t":{"$date":"2024-07-04T05:33:30.332+02:00"},"s":"F", "c":"-", "id":7033800, "ctx":"initandlisten","msg":"Attempted to yield locks but we are either not holding locks, holding a strong MODE_S/MODE_X lock, or holding one recursively"} {"t":{"$date":"2024-07-04T05:33:30.341+02:00"},"s":"F", "c":"ASSERT", "id":23089, "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":7033800,"file":"src\\mongo\\db\\concurrency\\lock_state.cpp","line":748}} {"t":{"$date":"2024-07-04T05:33:30.348+02:00"},"s":"F", "c":"ASSERT", "id":23090, "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"} {"t":{"$date":"2024-07-04T05:33:30.349+02:00"},"s":"F", "c":"CONTROL", "id":6384300, "ctx":"initandlisten","msg":"Writing fatal message","attr":{"message":"Got signal: 22 (SIGABRT).\n"}}

This error happens during index build: scanning collection.
Is there anybody that can help with such issue ?
Many Thanks,
Laurent.

2 months later

Upgrade your Mongo to v7.0 by upgrading binary files.
Then backup you data dir and try to repair with --setParameter "internalIndexBuildBulkLoadYieldIterations=2147483647" option.

Hi,
In my case, in order to solve this issue I did the entire procedure explained in this post : https://stackoverflow.com/questions/30974345/salvage-data-from-corrupted-mongodb

Meaning, I had to compile a wiretiger executable to salvage all wt files. After that and moving to last version of Mongodb 7 I executed multiple repair sessions. After a while, even if the repair never finished completely I could launch the server and use the database again.

This was a long process as the DB is bigger than 1.5 TB. This, sadly, exclude the test with the option you suggested. Thank you anyway.
Laurent.