[Date Prev][Date Next]
RE: multi-master syncrepl issue
> --On Tuesday, August 21, 2012 1:10 PM +0000 Chris Card <firstname.lastname@example.org>
> > Hi All,
> > In addition to the questions below (which I'd still like to see an answer
> > to), I have a further related question.
> > I now have 4 machines set up for multi-master replication of this
> > directory, and the contextCSNs were all in sync last week. One of the
> > machines was taken down for maintenance for a couple of days and has only
> > just come back up, so its contextCSN is way behind
> > (20120818093702.01462Z#000000#001#000000 compared
> > to 20120821130410.679339Z#000000#001#000000 as of now). This machine
> > has now been up and running for a few hours, but there's no sign of
> > replication catching up. Should ldap replication sort itself
> > out automatically and bring this machine's directory in line? Or do I
> > need to do something manually to force it?
> Do you have sync logging enabled?
Log level is set to none, so the slapd log doesn't give much help.
> 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.