Re: bdb corruption

[Matthew Burgoon <openldap-users@temporal.shutdown.com>]

Matthew Schumacher wrote:
>  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.

Yeah, I'm running a test with the DB_CONFIG file right now.

I also tried this using Solaris, albeit still with the sleepycat bdb, 
with the same bug. I couldn't find a stock Solaris berkeley db package 
in my sol9 dist. Maybe I should look more..

> 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?
>
> schu
>
> Matthew Burgoon wrote:
>
> > Greets all,
> >
> > 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 
> > search.)
> >
> > 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?