On Thu, Mar 10, 2022 at 12:30:49PM -0800, Quanah Gibson-Mount wrote:
--On Thursday, March 10, 2022 7:53 PM +0100 Michael Ströder michael@stroeder.com wrote:
I wonder what the operational requirements are when using syncprov-sessionlog-source cn=accesslog instead of the in-memory session log.
E.g. what about configured logpurge?
You should set logpurge to however long you want your replicas to stay out of contact with the provider. This is much more predictable than the in-memory sessionlog which has no guarantees about how long a CSN stays in there and can expire CSNs in an unexpected order.
What happens if the accesslog DB is completely deleted?
You lose the sessionlog. This is a significant flaw in the current design and is not what I was expecting when the need to implement a persistent sessionlog was identified.
If you completely drop the accesslog DB (which means you probably restarted), you're no worse than a restart with a traditional sessionlog - things fall back into a full present phase if a consumer wasn't up to date already. If you mess with the DB contents, you're on your own just like in deltasync.
Depending on the way in which the accesslog is configured, storing the sessionlog in it can be worse than the in-memory scenario.
That's why it's not a default, but from my point of view, the predictability you get with logpurge being time-based is much more appealing.
Additionally, it's not particularly useful/compatible with standard syncrepl since you have to fully implement storing delta's in the accesslog as well as the sessionlog for it to function, at which point you may as well just use delta-syncrepl instead of standard syncrepl.
If you configure syncprov-sessionlog-source, adding syncprov-sessionlog to the mix will do nothing except eat memory, as the manpage and the logs will happily point out. If you're using plain syncrepl, you have a choice to store and use accesslog or stay the traditional sessionlog, both work fine but sure, there are tradeoffs. Since AFAIK anything persisted needs to be an LDAP entry, the silver bullet just isn't available.
Regards,