--On Tuesday, February 03, 2009 10:37 PM +0100 Jonathan Clarke
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
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
> 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
Typically, this is the case on a newly installed server, with a
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! :)
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration