[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl
Howard Chu wrote:
Aside from allowing us to log that a conflict occurred, keeping the
oldCSN around doesn't seem to buy us much. Since the conflict
resolution is still determined solely by the current entryCSN, I'm
dropping this idea. All we need to check is if the incoming mod's
entryCSN is <= the current entryCSN and drop the change if so.
The oldCSN would still be needed to support multimaster with
delta-syncrepl. That would also allow us to do change-level conflict
resolution with delta-syncrepl instead of just entry-level as the
current code does. But at this point I'm not interested in adding that
support.
This is probably going to come back and haunt us.
Entry-level conflict resolution means if multiple changes are made to the
same entry on different servers at about the same time, only the change with
the newest timestamp will be saved, and the other changes will be lost.
To get finer granularity, delta-syncrepl and the oldCSN would be required.
When an incoming change's oldCSN doesn't match the current entryCSN we would
have to look back in the accesslog for the record matching the oldCSN, and
collect all of the changes made to the entry since that point. Walking
forward from that point, if we see that none of the previous changes affect
the same attributes as the incoming change, we can just accept the change and
there's no conflict.
If any of the attributes are the same, then we just do last-writer-wins on
each attribute:
For single-valued attributes just use the last known value.
If the last writer did a delete-whole-attribute mod, that's clear.
Otherwise, multi-valued attrs with a mix of deletes and adds, just play
them in sequence, with permissive semantics - ignore deletes on values that
were already deleted, ignore adds on values that are already present.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/