[Date Prev][Date Next]
RE: Master replication server reliability
- To: "Quanah Gibson-Mount" <email@example.com>, "Open LDAP Software List \(E-mail\)" <openldap-software@OpenLDAP.org>
- Subject: RE: Master replication server reliability
- From: "James Courtney" <Jcourtney@inphonic.com>
- Date: Thu, 12 Aug 2004 12:15:09 -0400
- Content-class: urn:content-classes:message
- Thread-index: AcSAFaIWUs1uwfK9RnG5/JAl4WsYUQAcWLew
- Thread-topic: Master replication server reliability
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?
From: Quanah Gibson-Mount [mailto:firstname.lastname@example.org]
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
> 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
> 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.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html