On Thu, Jun 16, 2022 at 15:20:39 +0200, Ondřej Kuzník wrote:
On Thu, Jun 16, 2022 at 03:03:53PM +0200, Geert Hendrickx wrote:
Yes, we see the replica's get an updated contextCSN with SID from the provider, only the provider itself makes no change to its contextCSN and stays with the old one, ie. the consumers appear to be ahead of this provider. So for me, the behaviour of 2.6 and master is still the same as 2.4/2.5.
Regarding your fix, you mean the replica (*each* replica?) will increase the contextCSN for its own SID for this operation? That seems strange to me, for a failed/refused update on another provider, I would expect no change at all on the replica's (and esp. the contextCSN associated with their SID's to never change as long as they receive no updates directly).
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.
Geert