[Date Prev][Date Next]
Re: commit: ldap/servers/slapd syncrepl.c
Howard Chu wrote:
The basic idea is this - on the provider, set up an accesslog DB for
logging changes, in addition to the main database. Set up the syncprov
overlay on the logging DB, not the main DB. Thus syncrepl will be
propagating full entries as usual, but the content of those entries
will actually be deltas, not actual entries... A sample config looks
like this:I guess there are two directions to go here - first, the accesslog DB
could be used by the sync provider as a non-volatile session log. That
would allow it to work efficiently across server restarts.
logsuccess TRUE # by default, accesslog logs failed requests too. we
just want successful writes.
On the consumer, the configuration looks like:
This separation of log info from syncprovider is rather troublesome;
it won't fallback properly to a full refresh if the consumer is too
far out of date wrt the log database.
A better implementation would be to leave the syncprovider overlay on
top of the main database, and add a config keyword telling it where it
can find a log database to use. Then both syncprov and accesslog
overlays would sit on the main database. And ideally, there would be a
new flag in the syncrepl control requesting that changes be propagated
in commit order, as deltas instead of full entries.
Next, I'm considering a secondary consumer config specifically for the
delta log. E.g.
The consumer can access the log in RefreshOnly or Persist mode; if the
Provider signals that the consumer is out of date then the consumer will
do a full refresh against the actual DB, and then return to using the
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/