Re: After power reset, LMDB sub-DBs' key-pairs are missing

[Arto Bendiken <arto@bendiken.net>]

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

-- 
Arto Bendiken | @bendiken | http://ar.to