Re: Persistent sessionlog

[Howard Chu <hyc@symas.com>]

Ondřej Kuzník wrote:
> ITS#8486 suggests we use a more efficient structure to maintain the
> sessionlog in. If we're messing with sessionlog already, we might as
> well see if we can address another issue - it is always empty on slapd
> startup leading to unnecessary full refreshes happening.
>
> slapo-accesslog has most of the data we need to support that and is
> already sorted in CSN order (much like sessionlog).
>
> AFAIK, we can't use the accesslog database directly as the database as
> we can't efficiently search on a single serverID to get the serverID
> set and the oldest CSN for each.

We could tweak the overlay to always maintain these in the parent entry 
(auditContainer). Currently the logpurge always sets the container's entryCSN 
to the oldest remaining CSN.

> There are a few tasks that need to be done in order to achieve this:
> - configure syncprov with a suffix that contains the slapo-accesslog
>    style logs for our DB
> - change struct sessionlog to use a more efficient structure that can be
>    iterated over from any point (only tavl is available at the moment)

We've talked about this before, an in-memory B+tree would be better for all of 
our AVL/TAVL uses.

> - on startup:
>    - iterate through the *last* N entries (filtering on successful write
>      ops that affect our suffix) and build slog_entry for each of those
>    - for each entry, insert a new slog_entry and update sl_mincsn
> - add a control to hint the database that we require the database to
>    iterate from the end backward (back-[mhb]db can support this)
> - update accesslog to log entryUUID for the entry that has just been
>    written
> - update the test suite to exercise the new failure conditions
>
> There are some caveats to this still:
> - if we aren't guaranteed to receive the accesslog entries in reverse
>    CSN order, the resulting sessionlog would be quite unsafe to use, we
>    have to try and detect this and start with an empty sessionlog
>    instead, resetting sl_mincsn set to match the database contextCSN
> - We might find an accesslog entry we can't use (modification that doesn't
>    have enough information), we should still be able to use whatever we
>    built until then, but can't continue


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/