Re: N-way replication "dn_callback : entries have identical CSN"

[Adrien Futschik <adrien.futschik@atosorigin.com>]

Le mercredi 18 février 2009 23:05:34, Jonathan Clarke a écrit :
> On 18.02.2009 15:49, Adrien Futschik wrote:
> > Le mercredi 18 février 2009 13:34:00, Jonathan Clarke a écrit :
> >> Le Mer 18 février 2009 09:24, Adrien Futschik a écrit :
> >>> I then switched to OpenLDAP 2.4.14 and did not have the problem anymore
> >>> (same
> >>> configuration). I guess this was a bug form 2.4.11.
> >>>
> >>> Still, I had a few of theses messages in the log :
> >>> conn=9 op=1 =>  bdb_dn2id_add
> >>> dn="cn=M2client2@laposte.net,ou=clients,o=edf,c=fr" ID=0xb: put failed:
> >>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995
> >>>
> >>> but I also got a few of theses :
> >>> dn_callback : entries have identical CSN
> >>> cn=M2client20@laposte.net,ou=clients,o=edf,c=fr
> >>> 20090217155418.854085Z#000000#002#000000
> >>> syncrepl_entry: rid=004 be_search (0)
> >>> syncrepl_entry: rid=004 cn=M2client20@laposte.net,ou=clients,o=edf,c=fr
> >>> syncrepl_entry: rid=004 entry unchanged, ignored
> >>> (cn=M2client20@laposte.net,ou=clients,o=edf,c=fr)
> >>> do_syncrep2: cookie=rid=004,sid=002
> >>> syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> >>>
> >>> Can anyone explain to me why ? is this normal ?
> >>> The dn_callback message comes from the master log-file where
> >>> "cn=M2client20@laposte.net,ou=clients,o=edf,c=fr" was inserted.
> >>
> >> I don't know about the DB_LOCK_DEADLOCK message, but "entries have
> >> identical CSN" means that your syncrepl consumer received an entry that
> >> is identical to one already present in your DB.
> >>
> >> This may happen when resynching a database, or it could be that your
> >> multi-master setup is causing each server to feed updates back to
> >> itself. Make sure the URLs in your syncrepl declarations match the
> >> listener URLs to slapd (-h option).
> >>
> >> Jonathan
> >
> > I dont think that the databases where resynching, it might be that the
> > master is trying to replicate with itself.
> >
> > Here is my configuration :
> > dn: olcDatabase={1}$BACKEND,cn=config
> > objectClass: olcDatabaseConfig
> > objectClass: olc${BACKEND}Config
> > olcDatabase: {1}$BACKEND
> > olcSuffix: $BASEDN
> > olcDbDirectory: ./openldap-data
> > olcRootDN: $MANAGERDN
> > olcRootPW: ${PASSWD}
> > olcDbIndex: default pres,eq
> > olcDbIndex: cn,sn pres,eq,sub
> > olcDbIndex: objectClass,entryCSN,entryUUID,seeAlso eq
> > olcDbIndex: mail,givenName,uid pres,eq,sub
> > olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple
> >    credentials=secret searchbase="$BASEDN" type=refreshAndPersist
> >    interval=$INTERVAL retry="5 5 300 5" timeout=3
> > olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple
> >    credentials=secret searchbase="$BASEDN" type=refreshAndPersist
> >    interval=$INTERVAL retry="5 5 300 5" timeout=3
> > olcMirrorMode: TRUE
> >
> > I have only 2 masters and m1 has two olcSyncRepl directives (one to
> > himself and on to m2). Is this normal ? I followed documentation and
> > based my test on test050-syncrepl-multimaster
>
> Yes, but you must make sure that slapd is launched on m1 and m2 with the
> exact same string $URI1 and $URI2 as used in your syncrepl config. For
> example:
> slapd -h $URI1
>
> The match is text based, so "ldap://1.2.3.4/"; is not the same as
> "ldap://1.2.3.4";, for example.
>
> If this is not the case, m1 will send and modifications to itself, and
> appear "surprised" that it already has them. Weird things may happen as
> a result. You can check pretty easily by reading the logs with loglevel
> stats, and make sure that m1 doesn't connect to itself.
>
> Jonathan

Hy Jonathan !

I am sure I used the same URI to start the instance and to configure syncrepl, 
but I'll check the logs to make sure it doesn't connect to itself.

I'll keep in touch with you.

Adrien