[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html