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: bugs@openldap.org Reporter: ondra@mistotebe.net 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.