Hi Howard,
On Mon, Mar 14, 2016 at 7:24 PM, Howard Chu hyc@symas.com wrote:
Arto Bendiken wrote:
As for the present problem, from further analysis what I suspect to be the reason those sub-DBs each contain their lone keys is that those three keys (one in each sub-DB) are the defaults inserted when the program initializes a new LMDB file to write to. Those three keys are inserted if the database is believed to be empty, i.e., if it has zero entries.
So possibly the post-reboot state of the DB file looked empty to LMDB, either for the main DB or for the three sub-DBs, and the program then proceeded to insert and commit those default keys. That's more plausible than a resurrection of the exact initial state (from months ago) where the original pages would indeed be long gone, as you noted.
I don't suppose there is much hope of finding the previous B+tree root(s) in the .mdb file and attempting to recover data from any still-reachable leaves?
If as you suspect, these 3 entries are present because they were automatically reinserted, then no, you're not likely to be able to recover anything. If the DB file had not been modified from it's actual crashed state, it would have been possible to access the previous transaction's meta page which would very likely have pointed to complete intact data. But when you wrote to the DB, you overwrote the previous meta page.
Thanks for confirming, I suspected as much. Bummer. I'll go ahead and proceed with restoring backups in this case, and will review the program logic to be more cautious in re-initializing what looks like (based on file size, last transaction ID, or other heuristics) a potentially-recoverable .mdb file instead of a genuinely new and empty one.
Thanks for you help, Arto