--On Tuesday, August 21, 2012 1:10 PM +0000 Chris Card ctcard@hotmail.com wrote:
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.
Chris