Re: multi master no syncing.

[Sébastien Bernard <seb@frankengul.org>]

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.

Seb

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