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

Re: Sporadic SLURPD replication problems

I compiled OpenLDAP as a 64 bit application instead of 32 bit. 
I am not sure whether this particular problem occurs in your situation as wel. 
In my logging I saw many occurences of "could not open replog.log" or "could 
not open replog.log.lock". When that happens, slapd just continues without 
writing anything to the replog. 
The Solaris  fopen() problem is not fully related to the amount of fd's set 
with ulimit. You could use the testprog provided by Sun under the following 
link to see how your system reacts:


Furthermore you should check your slapd logfiles because in my case the 
problem was caused by slapd and not by slurpd.


On Tuesday 29 July 2003 22:31, Jasen R. Baker wrote:
> Sure, I'm running Solaris 9 with Berkley 4.1 db as a backend. I've set the
> fd limit on each of the ldap systems via the /etc/system file to 4096 as
> well.
> How where you able to get around that problem you described below?
> Jasen
> -----Original Message-----
> From: Erik [mailto:edg72@home.nl]
> Sent: Tuesday, July 29, 2003 12:38 PM
> To: Jasen R. Baker
> Subject: Re: Sporadic SLURPD replication problems
> Jasen,
> 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 use.
> Regards,
> Erik
> 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
> > jbaker@infinityinternet.com
> > Manager - Systems Engineering
> > Infinity Internet