Re: Plain syncrepl vs. accesslog aka. ITS#9580 - proposal 3

On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ond=C5=99ej Kuzn=C3=ADk wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> proper deltasync yet if we don't want to abandon this functionality, we
> have to try and fill some in.

Now for proposal 3.

Most of the work is at the provider again:
If a consumer gets into a plain refresh, they pass that information
down in such a way that accesslog (and its syncprov) gets to find out.
If a syncprov sees this message, they will end running sessions with
e-syncRefreshRequired, having them fall back to a plain refresh too.

Accesslog also needs to record this (and the finalisation of that
refresh) in some way that also makes future consumers understand that
they (don't) need to fall back into plain, even in the case of
connection loss or other malfunction.

This accesslog message also acts like a poison that spreads through the
cluster, eventually all members will end up in plain refreshes. Taking
this approach requires a design that is guaranteed to upgrade everyone
back into a regular deltasync in a timely manner.

One possible approach might include an idea floated in the other
proposals where we have the provider commit to a CSN that refresh will
end with and commit that as a time limit on the poison we recorded into
our accesslog.

--=20
Ond=C5=99ej Kuzn=C3=ADk
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP