[Date Prev][Date Next]
Re: (ITS#4417) DELETE does not propagate in syncrepl'ed subordinate
Thanks for the report. This bug affected refreshAndPersist mode (which
is used in test033) but not refreshOnly. It is now fixed in HEAD and an
ldapdelete check has been added to test033.
> Version: 2.3.19
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (184.108.40.206)
> When an entry located in a subordinate (glued) syncrepl'ed database is deleted,
> the delete operations are not propagated to the replicated directory.
> This can be easily reproducted using test033:
> - run test033 with 'preserve' and 'don't stop' options : ./run -p -k test033
> - delete an entry from "ou=Information Technology Division, ou=People,
> dc=example, dc=com" on localhost:9011. This subtree is replicated to
> localhost:9012 :
> $ cat ld.ldif
> dn: cn=Barbara Jensen,ou=Information Technology
> changetype: delete
> $ ldapmodify -x -H ldap://localhost:9011 -D "cn=Manager 1,dc=example,dc=com" -w
> secret < ld.ldif
> deleting entry "cn=Barbara Jensen,ou=Information Technology
> <wait a few seconds>
> $ ldapsearch -LLL -H ldap://localhost:9012 -b "cn=Barbara Jensen,ou=Information
> Technology Division,ou=People,dc=example,dc=com" "" "objectclass"
> dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,
> objectClass: OpenLDAPperson
> The entrie is still there.
> Restarting both the master and the slave does not solve the problem.
> If deleting while slave is down, the entry is not deleted when the slave is
> Other operations seem to be correctly propagated.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/