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

Re: (ITS#6320) Replication Issues

--On Thursday, October 01, 2009 12:20 PM -0700 Jeff Doyle <j@telepaths.org> 

> Yes, that is the first thing attempted (both via using LOCAL4 -> syslog
> and via running slapd via cmd line)
> We see a brand-new server replicate all records (sids, csns, etc all look
> fine) without incident.  An existing server will receive, as I said, all
> of the changes ... at least for awhile.
> Nothing in the sync activity looks out of the ordinary (and I have read
> quite a few posts to be able to discern what the items inside mean)
> When a replication error occurs, often nothing at all is seen inside the
> logs (no error mesg,  no segfault, nothing) to indicate a failure has
> occurred.  Oftentimes, when SyncRepl fails to replicate, it is NOT during
> testing, so it is difficult for us to find out exactly WHEN the error
> occurred, as it could have happened at any point within the past 24 hrs,
> and up to a week ago.
> I can try to replicate this error deliberately. Unfortunately it is very
> difficult to make happen at-will.  My concern is that someone will try to
> close this ticket before I have witnessed the event.

Hm, I would suggest creating an accesslog database on the master that 
records all of your changes.  That way, you can look at the CSN stamp of 
what failed and look at the change in the accesslog DB.  It sounds like 
however that the replica syncrepl is simply failing to see the change occur 
on the master if it isn't logging anything about the missing change.



Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration