davidcoutadeur
commented
5 years ago Hi Mejdi,
lmdb is currently one of the more robust database worldwide. It means it requires a grave misonfiguration / system failure to generate a corruption. As you mentionned them: a partition non large enought, or a partition corruption.
From my point of view, once an administrator has managed the configuration, system, and hardware requirements, no problem should ever occur. Maybe could you ask to the OpenLDAP mailing list if you are sure the basics are fulfilled and the problem occurs again?
Regards,
David
Le 20/05/2019 16:02, mejdibennour a écrit :
Hello,
Since last week, we see a degradation of our ldap behavior in production. Counting the number of entries takes more than 15 minutes (it usually last less than 2 minutes). The backup take now 20 minutes but it took less than 4 minutes previously. We see that the disk access is used on read at almost 100%
We already had a similar behavior due to a mdb file corruption. The first time on march after a file system saturation on the system disk (the mdb file is on a secondary disk). A second time, on april after a VM uprgrade. Each time, we solved the issues by deleting the mdb file and letting it be created by replication.
Now, we don't understand the reason of this new corruption. But it is courious to see that the mdb file is corrupted once by month. Is there a bug or something that has an impact the mdb file? Is there a way to make the mdb more reliable?
We are using Openldap-ltb 2.4.47 on Ubuntu 16.04.2
Best Regards, Mejdi
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ltb-project/openldap-deb/issues/35?email_source=notifications&email_token=AB2Y6HOJJT5HRNDHEWLRH63PWKVO7A5CNFSM4HOCJHP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUXPTAA, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2Y6HJ5R4ZF7AXKZO4M7CDPWKVO7ANCNFSM4HOCJHPQ.
Hello,
Since last week, we see a degradation of our ldap behavior in production. Counting the number of entries takes more than 15 minutes (it usually last less than 2 minutes). The backup take now 20 minutes but it took less than 4 minutes previously. We see that the disk access is used on read at almost 100%
We already had a similar behavior due to a mdb file corruption. The first time on march after a file system saturation on the system disk (the mdb file is on a secondary disk). A second time, on april after a VM uprgrade. Each time, we solved the issues by deleting the mdb file and letting it be created by replication.
Now, we don't understand the reason of this new corruption. But it is courious to see that the mdb file is corrupted once by month. Is there a bug or something that has an impact the mdb file? Is there a way to make the mdb more reliable?
We are using Openldap-ltb 2.4.47 on Ubuntu 16.04.2
Best Regards, Mejdi