HI!
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?
What happens if the accesslog DB is completely deleted?
Ciao, Michael.
--On Thursday, March 10, 2022 7:53 PM +0100 Michael Ströder michael@stroeder.com wrote:
HI!
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?
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. Depending on the way in which the accesslog is configured, storing the sessionlog in it can be worse than the in-memory scenario.
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.
--Quanah
--On Thursday, March 10, 2022 12:30 PM -0800 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, March 10, 2022 7:53 PM +0100 Michael Ströder michael@stroeder.com wrote:
HI!
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?
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. Depending on the way in which the accesslog is configured, storing the sessionlog in it can be worse than the in-memory scenario.
To be clear, a complete deletion of the accesslog that doesn't also involve a slapd restart (which would also wipe the in-memory sessionlog) is only going to be caused by the purge interval firing. So using the accesslog backed sessionlog mandates having a suffiecently large purge interval. So one has to be particularly careful in how they configure the log purge interval for the accesslog DB.
Also, I'm not implying that the in-memory sessionlog is superior to the one stored in the accesslog DB. If you're using delta-syncrepl, the accesslog based one is definitely the way to go. If you're using standard syncrepl, you just have 2 bad choices.
--Quanah
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,
--On Friday, March 11, 2022 12:25 PM +0100 Ondřej Kuzník ondra@mistotebe.net wrote:
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.
The issue is that to use the disk based sessionlog, you also have to set up a full delta-based accesslog. If one could simply store only the necessary data for the sessionlog in the accesslog DB and skip the other ops then it would be a fine solution.
--Quanah
On Fri, Mar 11, 2022 at 10:47:53AM -0800, Quanah Gibson-Mount wrote:
--On Friday, March 11, 2022 12:25 PM +0100 Ondřej Kuzník ondra@mistotebe.net wrote:
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.
The issue is that to use the disk based sessionlog, you also have to set up a full delta-based accesslog. If one could simply store only the necessary data for the sessionlog in the accesslog DB and skip the other ops then it would be a fine solution.
As previously mentioned, it has to be an actual LDAP database, so the only way we could improve on this situation is by not storing reqMod: values. Everything else is either needed to make it a valid LDAP entry or necessary to support sessionlog.
Regards,
openldap-technical@openldap.org
-
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount