Re: backend requirements for syncrepl

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

> In my (preliminary) design, back-sql should act as a "dumb" syncrepl
> producer, i.e. a producer that is barely aware of the syncrepl control
> but can only answer in refreshOnly mode and simply responds to
> syncrepl searches.

That sounds like back-sql with entryUUID and entryCSN support.

> >I am currently into
> >the design of a changelog-based operatoin mode of syncrepl. Wondering
> >whether this would be sufficient for your case.
> >
> >
> mmmh, that's again the producer's side, I guess, so the point is that
> I don't see any reliable and generally portable way to know if the
> producer's data changed, I'm afraid.

Below is a rather verbose way of doing that :

1. search (with orig filter) with attr list of entryCSN, entryUUID
2. maxCSN = max(received entryCSN returned by Step 1)
3. delete those entries in the consumer side which is not present in the
search result of Step 1
4. if there is more than one entry in the result set of Step 1 whose
entryUUID is not
    present in the consumer replica or whose entryCSN is greater than the
consumer cookie then
        search( filter=(&(filter)(entryCSN<=maxCSN)(!(entryCSN<=cookie))),
                attrs=replicated attributes,entryCSN,entryUUID)
        add/modify the returned entry
5. if the result set of the Step 4 search is different from the returned
entries in Step 1 whose
    entryCSN is greater than the consumer cookie, some entries were deleted
after the search in Step 1.
    In this case, the above sequence can be repeated with an appropriate
retry interval depending on the application requirement.
6. update the consumer cookie to maxCSN