Hi Howard,

Many thanks for your suggestions. I am about to try what you've suggested (download and compile the latest master version of lmdb from git using master branch of  https://github.com/LMDB/lmdb).

However, just to note, I am running the latest version of zimbra which uses pretty recent version of openldap:


ii  zimbra-lmdb                 2.4.46-1zimbra8.7b amd64              LMDB Binaries
ii  zimbra-lmdb-lib:amd64       2.4.46-1zimbra8.7b amd64              LMDB Libraries
ii  zimbra-openldap-client      2.4.46-1zimbra8.7b amd64              OpenLDAP Client Binaries
ii  zimbra-openldap-lib:amd64   2.4.46-1zimbra8.7b amd64              OpenLDAP Libraries
ii  zimbra-openldap-server      2.4.46-1zimbra8.7b amd64              OpenLDAP Server Binaries


The problem that I am describing occurred with the above version of openldap.

I will keep you posted with any updates.


Cheers
Andrei

----- Original Message -----
> From: "Howard Chu" <hyc@symas.com>
> To: "Andrei Mikhailovsky" <andrei@arhont.com>, "openldap-technical" <openldap-technical@openldap.org>
> Sent: Thursday, 7 February, 2019 02:42:40
> Subject: Re: help with mdb database recovery after crash

> Andrei Mikhailovsky wrote:
>> Hello everyone,
>>
>> I have a bit of an issue with my ldap database. I have a Zimbra community
>> edition which uses openldap. A server crashed and I am unable to start the ldap
>> services after the reboot. The description of my problem, after some digging
>> about is:
>>
>>
>> the initial error indicated problem with the ldap
>>
>> Starting ldap...Done.
>> Search error: Unable to determine enabled services from ldap.
>> Enabled services read from cache. Service list may be inaccurate.
>>
>> Having investigated the issue, I noticed the following errors in the zimbra.log
>>
>> *slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized*
>>
>> I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb
>> in size and had reached the limit imposed by the ldap_db_maxsize variable. so
>> over the weekend, the LDAP mdb file became no longer sparse.
>>
>> I tried following the steps described in
>> https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database-is-90-full-in-zimbra/
>> but with no success, as the slapcat segfaults with the following message.
>>
>>
>> /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l
>> /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff
>> 5c583982 mdb_entry_decode: attribute index 560427631 not recognized
>> Segmentation fault (core dumped)
>>
>> the mdb_copy produces a file of 420 mb in size, but it still contains the
>> "mdb_entry_decode: attribute index 560427631 not recognized" error.
>> I've also tried mdb_dump, but had the same issues after using the mdb_load
>> command.
>>
>> I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 )
>> in the openldap community that the mdb gets corrupted if it reaches the maximum
>> defined size. but no solution of how to fix it.
>
> That's from over 3 years ago and has subsequently fixed. If you're running on
> such an old
> release, there's likely not much that can be done. Ordinarily it's possible to
> back up to
> the immediately preceding transaction, in case the last transaction is
> corrupted, but with
> that particular bug it's likely that the corruption occurred in an earlier
> transaction
> and has been carried forward in all subsequent ones.
>>
>> any advice on getting the database recovered and working again?
>
> You could try using the preceding transaction and see if it's in any better
> shape. The code
> for this is not released in LMDB 0.9. You can compile the mdb.master branch in
> git to obtain
> it. Then use the "-v" option with mdb_copy and see if that copy of the database
> is usable.
>
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/