cmikk@qwest.net wrote:
Full_Name: Chris Mikkelson Version: 2.4.26 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37)
When the provider sends a search response with state 'delete' with no / null cookie, the syncrepl consumer queues an locally-generated CSN and updates its context CSN with that. This appears to happen only with cookie-less deletion, not with cookie-less modification. I have not observed a cookie-less addition, so I do not know if it occurs there, too.
Thanks for the report. The bug only affected Deletes, not add or modify. Fixed in master.
Example logs from a pure consumer (no server-id, replicating from a provider with server id 002):
Sep 26 13:05:42 mpls-auth-02 slapd[57295]: do_syncrep2: rid=100 cookie= Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 be_search (0) Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 uid=<snip>,ou=improv,dc=qwest,dc=net Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_queue_csn: queing 0x7ffffe3fa560 20110926130542.130924Z#000000#000#000000 Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_graduate_commit_csn: removing 0x8f58a8a90 20110926130542.130924Z#000000#000#000000
This is problematic at our site because the provider cookie contains a SID 0 CSN from before we migrated to multimaster, and the SID 0 CSN recorded at the consumer renders the consumer state newer than the provider, breaking replication.