good evening;
i am looking for an explanation for a situation which we encountered with an lmdb database and library version is 0.9.17-3. the database's condition was such that all attempts to open it for reading failed. in at least some cases the error appears to have occurred during the operation which looked for stale leaders. a problem was also evident when attempting to copy the database:
@nl12:~# mdb_copy /srv/dydra/catalog/repositories/d2141030-9495-c040-b1a7-9e19edbeb491/ /srv/dydra/backups/public-data__rev mdb_copy: copying failed, error 131 (State not recoverable)
it was first evident in running processes which had already had the database open, but of which new threads were reopening the database environment. the only thing remarkable about the circumstances involved might have been that while several dozen threads were preparing reading simultaneously and in the processes of opening the environment to read, a monitoring thread took a snapshot of the threads, which entailed interrupting each to generate its stack trace.
once we identified and terminated all processes which had the environment open, successive open attempts succeeded. when we examined the content, however, although the space was still occupied on disk and the transaction id reflected the prior content, the indices were empty.
- what condition does that message intend to describe? - what can cause that condition? - would there have been some way to have recovered the old state - despite that message?