|
>I'm not sure I understand why full history is
needed. All that seems necessary is to have the backend keep the deleted
>entries around and just mark them as being deleted. They would only be
needed for the LDAP sync operations and not >show up for standard
searches.
It is more problematic with the scoped-out entries
by modify operations.
It is not possible to detect which entries were in
the previous search result
without the pre-modify contents of the
modified entry. This also applies for modrdn.
When the syncrepl supports both the operating
modes (log-based and state-based in other terms),
then the server will be able to switch between the
two modes. On the other hand,
if the state-based mode ([add+present]) is not
supported as is the case in the current LCUP proposal,
the only option when the history is not
enough would be to resort to a full reload,
which is far more expensive than the
state-based mode of operation.
Suppose you are using the syncrepl in its persist
mode.
There will be one initial refresh operation which
sends [add+presents].
Compared to slurpd, it seems more scalable than
the initial
db transmission that is required when the replica
went out of sync.
- Jong |