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

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



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
--
Jonathan Clarke
--
LinID - Open Source Identity Management
---------------------------------------------------------------
Linagora
27 rue de Berri, 75008 Paris
Tel: 01 58 18 68 28 / 06 99 60 03 10
---------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org/
---------------------------------------------------------------