RE: Master replication server reliability

["James Courtney" <Jcourtney@inphonic.com>]

I will try to build/install 2.2 in our dev environment today.  I believe
I've seen some emails on this list WRT fast loading using slapadd if
certain transaction parameters are set/disabled somehow in Berkeley DB.
Is this a practical/safe thing to do for data loading to a new server if
one re-enables things correctly when done?  Is this a standard practice
documented somewhere that I could educate myself on further?

Thanks!

Jamey



-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@stanford.edu] 
Sent: Wednesday, August 11, 2004 7:42 PM
To: James Courtney; Open LDAP Software List (E-mail)
Subject: Re: Master replication server reliability




--On Wednesday, August 11, 2004 8:43 PM -0400 James Courtney 
<Jcourtney@inphonic.com> wrote:

> I realized that it would be better to have two distinct emails with 
> descriptive subjects for my two issues...
>
> We moved to a replicated system yesterday (1 master and 2 slaves) and 
> our mail server components authenticate against the two slaves and our

> updates are done against the master which receives no other traffic.  
> The slave servers have been up since the change but the master server 
> has been going down from time to time.  I realized that my CGI was 
> very good about unbinding but wasn't calling disconnect on the LDAP 
> object when done so I've added this logic.  Could the failure to 
> disconnect rather than just unbind cause such problems.  The CGI would

> also exit after running each time so the client endpoint to the LDAP 
> server would go away with each run of the CGI.  I'd think that not 
> disconnecting explicitly before exiting in the code wouldn't be ideal 
> but wouldn't cause the slapd process great difficulty.  Would this 
> sort of thing be likely to cause severe slapd problems?
>
> Also, sometimes slurpd goes down and when it does I end up with a 2 GB
> (exactly) slurpd.replog file containing a great deal of redundant 
> update data.  Has anyone else seen this?  Slurpd seems to consume 20% 
> + of the CPU on a dual 2.4 Ghz. P4 system with 2 GB RAM while things 
> are running normally.  This seems excessive.  Is this symptomatic of 
> anything?
>
> Again my system is Redhat Enterprise 3 ES with OpenLDAP 2.1.25 
> (back-bdb), BDB 4.2.52, and OpenSSL 0.9.7d.
>
> Thank you all again for your time and wisdom.

There are threading issues in slurpd that are fixed in the 2.2 tree. 
Again, I suggest upgrading to OpenLDAP 2.2.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html