[Date Prev][Date Next]
Re: bdb corruption
From the reading I have been doing on this list, this is a bdb bug that
has no known timeline for a fix. Some people say it's avoidable by
setting a large cache size (big enough for your entire db) in your
DB_CONFIG file. Others avoid the problem by using solaris.
List: Please correct me if I'm wrong, but that is the conclusion I have
come to dealing with this problem.
Anyone know exactly what is going wrong in bdb, are they aware of the bug?
Matthew Burgoon wrote:
I've got a bit of a problem. I'm using OpenLDAP in a high volume
environment using the berkeley DB back end, and what's happening is that
every few days the database gets corrupted. Searches take excrutiatingly
long to complete. Sometimes I'm able to do a slapcat (even though it
takes forever, only a few entries a second) and rebuild the ldap
database with that, other times it can get so bad, that even the slapcat
fails (hangs with no more output half way through an entry) and I have
to restore from backup and the replication log.
I'm capable of reproducing the problem fairly easily, I just run a
couple copies of a script I wrote that just keeps doing searches, adds,
modifies and deletes randomly over and over again. Within 5 minutes, the
test ldap server is hosed. I've tried this with sleepycat bdb 4.1.25 and
openldap 2.1.22 and 2.1.23 on linux and solaris, all with the same results.
Simply restarting the server has no effect, the database has to be rebuilt.
I've tried using LDBM, but it's concurrency ability sucks (modifies,
other searches, etc are blocked while someone else is doing a complex
Has anyone else ran into this? Is there another berkeley db
implementation aside from sleepycat's? Any other suggestions, other back
ends that I can use?
- bdb corruption
- From: Matthew Burgoon <firstname.lastname@example.org>