[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Quanah Gibson-Mount wrote:
--On Tuesday, February 03, 2009 6:32 PM +0100 Jonathan Clarke <jclarke@linagora.com> 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