RE: multi-master syncrepl issue

[Chris Card <ctcard@hotmail.com>]

----------------------------------------
> Date: Tue, 21 Aug 2012 07:56:20 -0700
> From: quanah@zimbra.com
> To: ctcard@hotmail.com; openldap-technical@openldap.org
> Subject: RE: multi-master syncrepl issue
>
> --On Tuesday, August 21, 2012 2:50 PM +0000 Chris Card <ctcard@hotmail.com>
> wrote:
>
> >> Do you have sync logging enabled?
> >>
> >
> > Log level is set to none, so the slapd log doesn't give much help.
>
> Fix your log level.
olcLogLevel: sync ?
>
> >> In any case, with a server that large (3.5 million entries), I expect it
> >> will generally take a few months for it to catch up, since with standard
> >> syncrepl, it is going to try and refresh the entire database if it passed
> >> your sync ops log. I would strongly advise delta-syncrepl MMR instead,
> >> although that may take a significant amount of disk space for such a
> >> large DB if it is heavily active.
> >
> > The initial load of the directory via replication took < 2 days, so why
> > would it take months to catch up? I tried restarting slapd with the -c
> > flag specifying the current csn of the database, but it didn't seem to
> > make any difference - is that expected?
> > I'll take a look at using delta-syncrepl, since disk space isn't an issue.
>
> Syncrepl is slow, and your database will have constant changes even while
> replication is ongoing -- So if in 2 days it is caught up to where the
> other servers were two days ago, it will have to go back through and
> restart comparisons. So it may take well under a month, the point is, it
> will take a significant amount of time.
Would you expect catch-up with delta-syncrepl to much faster?
> In addition, it is going to have
> to take changes from 4 servers, which may cause deadlocks and other issues
> in the DB, assuming you're using BDB as the backend.
>
There are 4 servers, but all the changes go to one of them, the others are there as read-only servers, so 
I don't expect problems with deadlocking. I am also looking into mdb, but that's an issue 
for another thread.