Hello,
I run an LDAP directory on 3 servers : one master, and two slaves, synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and openLDAP 2.4.13.
I encountered yesterday an issue with syncrepl that should have been solved with openLDAP 2.4.13
http://www.openldap.org/lists/openldap-software/200812/msg00040.html
The synchronisation was blocking on the deletion of a facsimileTelephoneNumber.
When the problem occured, the master entry was (only showing the facsimileTelephoneNumber attribute) : dn: uid=veinantep,ou=uds,ou=people,o=annuaire facsimileTelephoneNumber: 0388613347
And the slave entry was : dn: uid=veinantep,ou=uds,ou=people,o=annuaire facsimileTelephoneNumber: 0388612908 facsimileTelephoneNumber: 0388613347
The application doing the modification on the master is always using a "replace" operation, to avoid the "no equality matching rule" problem. It seems that syncrepl tries to synchronise the slave by generating the forbidden operation of deleting a precise facsimileTelephoneNumber.
Is this problem known ? the release between 2.4.13 and 2.4.16 don't mentionned something about it.
I managed to unlock the situation by completely deleting the "facsimileTelephoneNumber" on the master, then adding it again.
The big problem of this little issue is that it is blocking all the synchronisation process between master and slaves ...
By the way, is there a way to check the good state of the synchronisation with syncrepl (besides parsing the sync logs or doing recurring diff between the servers) ? I must admit that I miss slurpd's .rej files.
Just in case, here are the log of one of the slaves :
syncrepl_entry: rid=101 be_search (0) syncrepl_entry: rid=101 uid=veinantep,ou=uds,ou=people,o=annuaire bdb_modify: uid=veinantep,ou=uds,ou=people,o=annuaire bdb_dn2entry("uid=veinantep,ou=uds,ou=people,o=annuaire") bdb_modify_internal: 0x0001fc23: uid=veinantep,ou=uds,ou=people,o=annuaire <= acl_access_allowed: granted to database root bdb_modify_internal: delete facsimileTelephoneNumber bdb_modify_internal: 18 modify/delete: facsimileTelephoneNumber: no equality matching rule bdb_modify: modify failed (18) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=18 matched="" text="modify/delete: facsimileTelephoneNumber: no equality matching rule" null_callback : error code 0x12 syncrepl_entry: rid=101 be_modify (18) syncrepl_entry: rid=101 be_modify failed (18)
Thanks,
--On Friday, July 10, 2009 10:21 AM +0200 Alain ZAMBONI Alain.Zamboni@unistra.fr wrote:
Hello,
I run an LDAP directory on 3 servers : one master, and two slaves, synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and openLDAP 2.4.13.
I encountered yesterday an issue with syncrepl that should have been solved with openLDAP 2.4.13
Yeah, I'm pretty sure this has been solved since, as I recall running into it at one point.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hello,
I run an LDAP directory on 3 servers : one master, and two slaves, synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and openLDAP 2.4.13.
I encountered yesterday an issue with syncrepl that should have been solved with openLDAP 2.4.13
Yeah, I'm pretty sure this has been solved since, as I recall running into it at one point.
The problem just happened again. It it possible that it is only half solved, or that my config present some errors ?
slave :
oclSyncrpepl: {0}rid=101 provider=ldap://amon.u-strasbg.fr:389 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(objectclass=*)" searchbase="o=annuaire" scope=sub schemachecking=off type=refreshAndPersist retry="60 +"
master:
18 olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 olcSpSessionlog: 1000
It's a very serious problem for me, because when this happens, no other modification is replicated. Is there some config parameter to prevent this blocking ?
I plan an upgrade to 2.4.17. I Hope this will help.
openldap-technical@openldap.org