Re: (ITS#8125) MMR throws away valid changes causing drift

[hyc@symas.com]

Ond=C5=99ej Kuzn=C3=ADk wrote:
> On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc@symas.com wrote:
>> ondra@mistotebe.net wrote:
>>>    Also, whenever we fall back from deltasync into plain syncrepl, we
>>>    should make sure that the accesslog entries we generate from this =
are
>>>    never used for further replication which might be thought to be a
>>>    separate issue.
>>
>> That should already be the case, since none of these ops will have a v=
alid CSN.
>=20
> I faintly remember Quanah seeing these accesslog entries used by
> consumers at some point, but I might be mistaken.
>=20
> The more general point is making sure its potential syncrepl consumer
> not even try and use the accesslog entries we added before these - the
> refresh has created a strange gap in the middle (or worse, duplicated
> ops if a contextCSN element jumped backwards). But if we enforced that,
> the question is how to get modifications originating from this replica
> replicated elsewhere - unless we decide they can't be salvaged?

We could set the replica to reject user mods while in refresh phase. Not =
sure
how friendly that is, whether apps would be smart enough to retry somewhe=
re else.

> And should the contextCSN reset terminate not just all inbound syncrepl
> sessions, but the outbound ones as well?

Need to be careful about race conditions here, or you could end up with a=
ll
nodes just terminating each other and everything halting.

--=20
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/