https://bugs.openldap.org/show_bug.cgi?id=9580
Issue ID: 9580
Summary: Refresh vs. accesslog in delta-MPR
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: overlays
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
A server consuming a plain syncrepl session (might be a delta-MMR refresh)
still has to log the entries into accesslog, however that accesslog stops being
capable of serving as a delta-sync source:
- operation entryCSNs will be out-of-order
- the changes logged will not be the intended modifications (e.g. if we fell
back after a conflict, the conflicting entry will be replaced with the other
version, other examples available)
We need to deal with that somehow, at the very least we need to make sure the
consumer will not take them at face value. We could record this in the
accesslog root entry if we can detect when this starts and match it up with the
final cookie, syncprov would still need some tweaks to understand it.
We could mark the entries received this way and make sure delta-consumers treat
them as "poison", as if they were running a plain syncrepl session themselves
(not update contextCSN until that's finished, mark its own accesslog entries
this way, ...). Anything like that needs guarantees that it will clean itself
up once all of the real plain sessions finish otherwise we've lost delta-sync
altogether.
A different approach might or might not be needed for live delta-persist
sessions replicating from a refreshing provider, but at least that syncprov has
a way of detecting this live if it chooses to.
--
You are receiving this mail because:
You are on the CC list for the issue.
