On Thu, Jun 16, 2022 at 03:52:32PM +0200, Geert Hendrickx wrote: > On Thu, Jun 16, 2022 at 15:20:39 +0200, Ondřej Kuzník wrote: >> Yes, exactly. The accesslog is a DB like any other and you've chosen to >> add the entries that need an entryCSN of their own. Don't see a way out >> of that? On a pure replica it's just not involved in replication, on a >> provider, the accesslog shouldn't stay ahead for long? The NEW_COOKIE >> message should loop back to it AFAIK, but would need to test that. > > No, I'm speaking of the ContextCSN of the *main DIT*, not of the accesslog. > A no-op like deleting a non-existing object updates the ContextCSN of the > main db on the replica's but not on the provider. We monitor (the diff > between) the contextCSN's so it's indicates the provider is "behind" the > consumers here.
I have tried reproducing this and the only DB that has contextCSN changes is the accesslog DB, the main DB stays intact. Please provide an example setup with 2.6 or master where you're seeing the above behaviour. Are you sure it's not something like ppolicy that makes changes to the local DB instead? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
