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
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
Adrien
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
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
openldap-technical@openldap.org
-
Adrien Futschik -
Jonathan Clarke