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

Re: multi master no syncing.



--On Monday, October 17, 2011 4:38 PM +0200 SÃbastien Bernard <seb@frankengul.org> wrote:

Le 24/09/2011 01:43, Howard Chu a Ãcrit :
SÃbastien Bernard wrote:
Hi,

I've setup a multimaster cluster composed of two machine (in my example
192.168.0.204 and 192.168.0.197).
Everything is working ok and both side are replicating ok.

However, I've a problem I'd like to submit to your sagacity.

When I put down a server, and modify the other server (delete or add),
when the first server comes back, the modifications are not pushed in
the old server.
Server 1 says Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by
peer, ignored

You have not provided enough useful information (OpenLDAP version,
exact server configurations, which one is "server 1" in your
description) to be certain. But most likely you have not configured
their ServerIDs correctly.

Adding new entries works ok and synchronisation happens but for the
nodes altered while one of the servers was down, the modifications are
lost (or more precisely ignored by the other).

My questions: I
      Is this normal behaviour (Maybe I got the configuration wrong) ?
      How may I force the missing entries to be replicated to the
other ?
(Only solution I found is to wipe the entire database on the down server
that force a replication from its peer).

sincerely,
Seb


Ok, now that I've understood my mistakes, everything is working as soon
as I modified the command line of each server so that they can manage
know who they are.

The warning is in the admin guide but not visible enough.
This is the reason why I'm proposing the little modification attached to
my mail.

1- It explicitly state that the server must be run with one of the url.
2- it make the replication of cn=config not mandatory. This is confusing
at best, and the way I understood it is that you must replicate cn=config
for the N-way master to work where as it is just a convenient way to
deploy replication configuration on each server.

The result is not really crytal clear. IMHO,  the best way would be to
separate the two options in two example, and state explicitely the
benefits of replicating the cn=config too.

Please file an ITS about this at http://www.openldap.org/its/ so the documentation updates can be appropriately tracked. Thanks!

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration