[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#7052) Spurious CSNs being recorded on syncrepl consumers.



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.

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.