Re: Initializing cn=config from existing multi-master setup via syncrepl - "new entry is older than ours"

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Tuesday, February 03, 2009 10:37 PM +0100 Jonathan Clarke 
<jclarke@linagora.com> wrote:

> Q
> Absolutely - this is the aim, to integrate a new master server into the
> existing multi-master cluster. Sorry if I was not clear, our aim is not
> to set up a simple replica, but an extra full blown master (N+1 of a
> N-way multimaster setup).

Then you need to do the steps I outlined: slapcat one of your master's 
cn=config trees, and slapadd that onto the new master and start it.  Then 
all the entries will have the right timestamps, and everything will 
replicate as appropriate.

> We are basically attempting to industrialize adding a server to a cluster
> of existing multi-masters in a load-balancing setup. The idea is to save
> as much manual copying as possible, and enjoy the "magic" of multi-master
> replication coupled with cn=config :))

Use the above to correctly seed the new master's cn=config tree.

> > If you really want to have fun, set up another database on the master to
> > store the cn=config tree for replicas under a different branch, and then
> > use slapo-rwm to rewrite it as a config tree for any replica that
> > connects to it.  This should work in theory, although I've never done it.
>
> In theory too (I have not tested since I'm away from the test machines
> right now), this would produce the same symptom as I described originally
> - the entries from the pseudo-cn=config branch on the master would be
> detected as older than the local, new cn=config entries, and be rejected.

No, it wouldn't.  You're missing the overall point of what I'm talking 
about here.  In this setup, you would have two config trees.  One for the 
various masters, rooted at "cn=config" on the master servers.  Then you 
would have one on the master servers(rooted, at, say "cn=config-replica") 
for the replica's cn=config tree.  Then you would use slapo-rwm for the 
replicas to rewrite calls to the masters for cn=config to actually read 
from the cn=config-replica tree.  Again, you would still want to do the 
initial seed on these replicas via slapcat/slapadd.  That will always be 
your basic first step, and will fully avoid the issue you are hitting. 
This way, you can have multiple configuration trees for different types of 
servers.

> Typically, this is the case on a newly installed server, with a freshly
> slapadd-ed cn=config - CSN's will have a timestamp more recent than the
> other masters' config.

No, the CSNs when you use a slapadded cn=config will *not* be more recent. 
They'll be preserved to be what they were when the slapcat was done. 
That's why it avoids this problem.

> Thanks for your reply Quanah.

No problem! :)

--Quanah


--

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