Hi Howard, On Mon, Mar 14, 2016 at 7:24 PM, Howard Chu <[email protected]> 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 -- Arto Bendiken | @bendiken | http://ar.to
