While testing sync replication, I encountered a situation in which a previously deleted DN cannot be added again because the ldapadd command receives a 68 error code. If I perform an ldapsearch command for the DN, the DN is not found. If I try to add the DN, the add fails with a 68 error code. If I perform a slapcat command for that DN, slapcat displays the record. I have removed all BDB index files and rerun the slapindex command, but the DN is still not found with the ldapsearch command and fails to be added because of a 68 error code. 1 reason I can think of is that deleting a DN does not physically delete the record, but flags the DN as being logically deleted. This condition does not happen all the time, but it does happen eventually after I have been adding, modifying, and deleting records for approximately 15 minutes.
I'm running openLDAP 2.4.17 with BDB 4.6.21 (and have not applied the 4 BDB patches). Running sync replication with 2 masters defined in mirror mode using refreshandpersist; issuing LDAP commands against only master slapd #1.
Barry Colston
--On Tuesday, August 18, 2009 10:22 AM -0400 Barry Colston bcolston@xtec.com wrote:
I'm running openLDAP 2.4.17 with BDB 4.6.21 (and have not applied the 4 BDB patches).
Hm, maybe there's a reason there are patches released.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I applied the 4 4.6.21 BDB patches, reran my tests, and the problem is still occurring.
Ldapsearch fails to find the record. Ldapadd fails with an error code of 68. Slapcat performed against the server where the delete command was issued displays a record, but the record is listed with an objectClass and structuralObjectClass of "glue" (which are different than when the record was added.) Slapcat performed against the 2 other master servers where the delete command was not issued do not display a record.
Barry Colston
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, August 18, 2009 3:56 PM To: Barry Colston; openldap-technical@openldap.org Subject: Re: ldap_add: Already exists (68) errors when testing multi-master sync replication
--On Tuesday, August 18, 2009 10:22 AM -0400 Barry Colston bcolston@xtec.com wrote:
I'm running openLDAP 2.4.17 with BDB 4.6.21 (and have not applied the 4 BDB patches).
Hm, maybe there's a reason there are patches released.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, August 19, 2009 1:33 PM -0400 Barry Colston bcolston@xtec.com wrote:
I applied the 4 4.6.21 BDB patches, reran my tests, and the problem is still occurring.
Ldapsearch fails to find the record. Ldapadd fails with an error code of 68. Slapcat performed against the server where the delete command was issued displays a record, but the record is listed with an objectClass and structuralObjectClass of "glue" (which are different than when the record was added.) Slapcat performed against the 2 other master servers where the delete command was not issued do not display a record.
To be clear, you are saying you can reproduce this situation from a point in your database where the situation did not previously exist? Or are you simply saying that after patching BDB, you end up in the same spot? Although if it is being reported as a glued entry, that seems more like an OpenLDAP level issue than a BDB one. If you can easily recreate the problem, I suggest filing an ITS about it with the steps to reproduce.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Barry Colston -
Quanah Gibson-Mount