[Date Prev][Date Next]
Re: Sporadic SLURPD replication problems
Please provide some extra information like the OS you are running on, the
backend you are using on etc.
I recently found a problem with Solaris 32 bit whereby the slapd could not
open the replica.log.lock or the replica.log file and thus failed to
replicate. It appeared to be a problem with fopen() on Solaris that can only
handle fd's between 0 and 255 while slapd at that moment had > 300 fd's in
On Tuesday 29 July 2003 01:10, Jasen R. Baker wrote:
> Question for those with any answer.
> I currently have a master/slave setup running OpenLDAP 2.22
> I'm having sporadic replication problems. I set slurpd to debug mode -d
> 65535 to watch all requests as they came in. What I'm finding is if I make
> a change to the master, sometimes I'll see data sent via SLURPD to my
> secondary ldap server and it writes the updat as it should.
> Other times I don't see anything in the debug logs and nothing is written
> to the slave LDAP server. The only thing I DO see is the time stamp on the
> /usr/local/ldap/var/replica.log.lock file is updated, but the timestamp on
> the /usr/local/ldap/var/replica.log file is not.
> Our ldap server gets a tremendous amount of simultaneous requests, I don't
> know how exactly to measure it, but our slapd process on the master server
> runs conststent at abou 60%+ cpu. I'm not sure if load has anything to do
> with it.
> Both ldap servers are in sync when I do these tests and I restart them both
> and remove all of the replog and slurpd.replog files and lock files just to
> be safe and it only takes a couple of requests before it fails to replicate
> to the slave server.
> Jasen Baker
> Manager - Systems Engineering
> Infinity Internet