Quanah Gibson-Mount wrote:
--On Tuesday, February 03, 2009 6:32 PM +0100 Jonathan Clarke
<[email protected]> wrote:
Hi all,
We have setup a couple of servers in N-way multimaster config, using
back-config, as explained in the admin guide. These all use RE24,
checked out today.
We are now trying to add another server to the existing cluster. To do
this, we want to replicate the existing cn=config branch from the
cluster, to initialize the config for the new server.
To do this, we start the new server with a minimal cn=config branch,
making it a syncrepl consumer to an existing server (consumer only, no
multimaster on this new server):
How do you expect to replicate the cn=config branch from a multi-master
and end up with only a replica? I'm lost. Once it finishes, it'll be a
multi-master, not a pure replica.
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).
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 :))
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.
My question could be put more broadly: how can you tell syncrepl that is
really *just* a slave, and replace everything it has with content from
the master, even if one of it's own entries is more recent according to
the CSN? The current behavior is to keep the most recent modification,
thus comprising the replica's integrity.
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.
Thanks for your reply Quanah.
Regards,
Jonathan
