[Date Prev][Date Next]
Re: Sporadic SLURPD replication problems
- To: "Jasen R. Baker" <firstname.lastname@example.org>
- Subject: Re: Sporadic SLURPD replication problems
- From: Erik <email@example.com>
- Date: Wed, 30 Jul 2003 21:18:00 +0200
- Cc: openldap-software@OpenLDAP.org
- Content-disposition: inline
- In-reply-to: <2C8BB28F11F9114799C4B80E4CDA55C523B463@usnet-ex01.usnet.corp>
- References: <2C8BB28F11F9114799C4B80E4CDA55C523B463@usnet-ex01.usnet.corp>
- User-agent: KMail/1.5.2
On Wednesday 30 July 2003 19:53, you wrote:
> Thanks, I'll try that link. Which level of debugging did you have slapd
> running into to see the errors about the replog?
> -----Original Message-----
> From: Erik [mailto:firstname.lastname@example.org]
> Sent: Wednesday, July 30, 2003 10:58 AM
> To: Jasen R. Baker
> Cc: openldap-software@OpenLDAP.org
> Subject: 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:email@example.com]
> > 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
> > > firstname.lastname@example.org
> > > Manager - Systems Engineering
> > > Infinity Internet