--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