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

Re: multi master no syncing.

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

I've setup a multimaster cluster composed of two machine (in my example and
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).


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.

diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf
index dde9a63..6cc436b 100644
--- a/doc/guide/admin/replication.sdf
+++ b/doc/guide/admin/replication.sdf
@@ -778,6 +778,11 @@ This sets up syncrepl as a provider (since these are all masters):
 Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):
+Note: One can build a working N-way master replication without the cn=config replication.
+In this case each server has an olcServerID without any url mentionned and each server
+will know exactly who it is since the configuration is not abiguous. You can skip the
+following section alltogether to the modification of olcDatabase={1]$BACKEND,cn=config.
 >     dn: cn=config
 >     changetype: modify
 >     replace: olcServerID
@@ -809,6 +814,12 @@ Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with you
 Now start up the Master and a consumer/s, also add the above LDIF to the first consumer, second consumer etc. It will then replicate {{B:cn=config}}. You now have N-Way Multimaster on the config database.
+Note: Each server {{B:must}} reference their respective URL in the command line they are run with.
+Else, they will not be able to recognize their identify and you will end up with glitches in the replication like nodes not replicating.
+For example, server1 must be run with:
+>	slapd -h $URI1
 We still have to replicate the actual data, not just the config, so add to the master (all active and configured consumers/masters will pull down this config, as they are all syncing). Also, replace all {{${}}} variables with whatever is applicable to your setup:
 >     dn: olcDatabase={1}$BACKEND,cn=config